[!NOTE]
For any questions, you can contact dsl@revanced.app or contact us through our social media platforms listed on ReVanced's official website. Alternatively, you can use this issue for discussion.
Soon, ReVanced Patcher v20 will be released. The APIs have been converted to Kotlin DSL, but backward compatibility is not retained, leading to breaking changes.
As a heads-up before Patcher v20 is fully released and integrated into ReVanced Manager, I am manually reviewing a couple of repositories. Once ReVanced Manager updates, your patches will stop working due to the breaking API changes.
The ReVanced Patches template repository has already implemented the necessary changes and serves as a basis for updating your patches to the new APIs: ReVanced Patches template repository.
I recommend familiarizing yourself with the new API and checking out the respective branch in the ReVanced Patches template repository to migrate your patches to the new API. It is not recommended to manually bump ReVanced Patcher. Instead, use the template repo as a basis because it now employs the ReVanced Patches Gradle plugin, which reduces build system boilerplate for ReVanced Patches developers. Using that plugin, you can automatically apply updates to the build system of ReVanced Patches without worrying about it yourself.
If You Also Developed Integrations for Your Patches:
ReVanced has merged integrations with patches, meaning you no longer need a separate repository to write integrations. The build system compiles the integrations and adds them to the patches, with ReVanced Patcher handling the rest. Therefore, it is recommended to use the template repository as this build system is handled by the Gradle plugin already applied in the template.
Extensions are now on a per-patch basis. Previously, you usually had one integration merged with the app you were patching. Because patches are modular by design, extensions are also now on a per-patch level. Each patch can ship its extension. Extensions can be compiled against each other for interoperability. If it is difficult to separate the extensions for now into their respective patches, you can create a single patch that ships your one big extension for now and migrate to separate extensions over time. Other patches can depend on that patch which would make ReVanced Patcher merge the extension of the patch, which all the other patches can use just like with integrations.
Update your current patches to the new API and merge integrations into the same repository
[!CAUTION]
Both the Gradle plugin and Patcher v20 are still in development. They are subject to have further breaking changes or bugs. If you encounter any issues, please open an issue in the respective repository.
[!TIP]
Once we release everything, you can simply update the plugin and ReVanced Patcher dependency to use the new release version. Make sure to confirm if the template has not received any changes you may want to mirror to yours.
[!NOTE]
If you want to test your changes, you will need to check out this branch in ReVanced CLI: ReVanced CLI branch. Additionally, you need to check out this branch in ReVanced Library: ReVanced Library branch and publish it to the local Maven repository so ReVanced CLI can use it.
Soon, ReVanced Patcher v20 will be released. The APIs have been converted to Kotlin DSL, but backward compatibility is not retained, leading to breaking changes.
As a heads-up before Patcher v20 is fully released and integrated into ReVanced Manager, I am manually reviewing a couple of repositories. Once ReVanced Manager updates, your patches will stop working due to the breaking API changes.
The ReVanced Patches template repository has already implemented the necessary changes and serves as a basis for updating your patches to the new APIs: ReVanced Patches template repository.
ReVanced Patcher v20 API documentation is also available for reference: ReVanced Patcher API documentation.
I recommend familiarizing yourself with the new API and checking out the respective branch in the ReVanced Patches template repository to migrate your patches to the new API. It is not recommended to manually bump ReVanced Patcher. Instead, use the template repo as a basis because it now employs the ReVanced Patches Gradle plugin, which reduces build system boilerplate for ReVanced Patches developers. Using that plugin, you can automatically apply updates to the build system of ReVanced Patches without worrying about it yourself.
If You Also Developed Integrations for Your Patches:
ReVanced has merged integrations with patches, meaning you no longer need a separate repository to write integrations. The build system compiles the integrations and adds them to the patches, with ReVanced Patcher handling the rest. Therefore, it is recommended to use the template repository as this build system is handled by the Gradle plugin already applied in the template.
ReVanced Patcher v20 API documents how integrations (now called extensions) work: ReVanced Patcher documentation.
Extensions are now on a per-patch basis. Previously, you usually had one integration merged with the app you were patching. Because patches are modular by design, extensions are also now on a per-patch level. Each patch can ship its extension. Extensions can be compiled against each other for interoperability. If it is difficult to separate the extensions for now into their respective patches, you can create a single patch that ships your one big extension for now and migrate to separate extensions over time. Other patches can depend on that patch which would make ReVanced Patcher merge the extension of the patch, which all the other patches can use just like with integrations.
Here's an example by ReVanced:
TL;DR
ReVanced Patcher v20 will be released soon and will introduce breaking APIs. Until ReVanced Manager updates, do the following: