Unveiling How RePlugin’s Gradle Plugins Automate Host & Plugin Build Processes

replugin-host-gradle

1. Based on the host build.gradle configuration, it generates a transitional RePluginHostConfig.java file, similar to the usual BuildConfig.java. The file is placed under

app\build\generated\source\buildConfig\{productFlavors}\{buildTypes}\{applicationId}\gen\

and packaged into the DEX for the host to use.

2. According to the host build.gradle, it creates placeholder entries for the four main Android components in the host AndroidManifest.xml. The number of placeholders is configurable via the repluginHostConfig closure.

3. It reads the assets/plugins directory, parses the built‑in plugins (APKs), and automatically generates a descriptor file plugins-buildin.json, which is packaged into the host APK.

Gradle Build Process

Gradle treats each project as a collection of tasks. The build proceeds in three phases: initialization (executing settings.gradle), configuration (parsing each build.gradle and constructing a directed acyclic graph of tasks), and task execution (running tasks in dependency order).

Example task graph for assembleDebug shows tasks such as :app:preBuild, :app:generateDebugBuildConfig, :app:processDebugManifest, :app:transformClassesWithDexForDebug, etc. By inspecting this graph, developers can insert custom tasks before or after specific default tasks.

Key custom tasks added by RePlugin: generateHostConfigTask (depends on generateBuildConfigTask) creates RePluginHostConfig.java.

A task inserted after processDebugManifest adds the four component placeholders to AndroidManifest.xml. generateBuiltinJsonTask (depends on mergeAssetsTask) creates plugins-buildin.json and packages it into the APK.

replugin-plugin-gradle

This plugin is used in the plugin project. During compilation it employs the Transform API (introduced in Android Gradle 1.5.0) to modify Java bytecode before the .class files are converted to .dex. It enables non‑intrusive changes such as rewriting activity inheritance and redirecting API calls.

The Transform workflow is illustrated below:

Bytecode manipulation is performed with the open‑source Javassist library, which can edit and generate Java bytecode dynamically.

Principle Analysis

RePlugin creates an isolated Context and Resource for each plugin. At plugin load time, the created Context is assigned to the plugin’s components, allowing them to use their own resources.

For activities, the host injects the custom Context via the plugin activity’s attachBaseContext() callback, using RePluginInternal.createActivityContext() which reflects the host’s method.

Instead of requiring developers to subclass a custom PluginActivity, RePlugin’s Transform API rewrites all activity inheritance in the bytecode to point to the prepared PluginActivity class.

ContentProvider handling follows a similar pattern: the host reserves placeholder providers in its manifest. At runtime, RePlugin maps the requested provider URI to the placeholder URI. The Transform API rewrites calls like getContentResolver().insert() to PluginProviderClient.insert(), which performs the necessary URI redirection.

Task Run Graph for replugin-plugin-gradle

After registering a custom Transform implementation (named ___ReClass___), the task graph includes a new task transformClassesWith___ReClass___ForDebug that runs before the transformClassesWithDexForDebug task, ensuring the modified bytecode is packaged into the final DEX.

Consequently, the APK produced with replugin-plugin-gradle contains bytecode that conforms to RePlugin’s rules, enabling seamless plugin integration without manual code changes.