WXDynamicPlugin keeps the Android host app almost empty

Zero reflection, no hooking, and the argument behind it

The central claim of WXDynamicPlugin is that it implements plugin loading without reflection and without hooks, and the project backs that with a policy argument rather than only a performance one. The stated reasoning is that this way no compatibility work against any system version is required and no hidden API is called, so the approach does not conflict with the policy Google applies to access of non-public SDK interfaces. That is a meaningful difference in risk profile for a plugin framework, because the usual alternative approaches depend on private platform surfaces that can change without notice and that draw scrutiny from app store review. The framework is written in Kotlin, licensed under Apache-2.0, and the project has been updated to AGP 8.6 and Kotlin 2.0.20 with Compose support, according to a linked configuration write-up. The last push to the repository was on 2026-05-26 and the project publishes no tagged releases.

Everything except the plugin download logic can itself be a plugin

The unusual part of the design is that the framework's own code is treated as replaceable. The README argues that a complete plugin framework is hard to build in one pass, so WXDynamicPlugin makes everything dynamic, which means the plugin framework code becomes a plugin, and the host's plugin download logic and version control can be pluginised too. The download, version control and loading logic, and the framework code itself, are all described as dynamic. The claim made against other frameworks is that none of them make the logic that downloads plugins to the local device dynamic in the same way. For a team that has been burned by a framework that needed a host release to fix a download bug, that is the most interesting property in the project, and it is also the one that puts the most operational weight on your own server.

Size and timing figures the project puts forward

The performance story is stated in concrete numbers, and they are the numbers to test first. The project claims the compiled plugins are as small as possible, with all plugin modules together loading at under 500k and a single module around 70k, and it compares this with other plugin frameworks where compiled plugin size is said to be above 3M. The host integration is claimed at just over 4K of code, with download logic, version control and load integration bringing the total to around 60k and roughly 80 methods. The timing claims follow from the size: on a 4G network a 500k plugin download is put at about 500ms, whereas a 3M plugin would take at least ten seconds to download and then two to three seconds to load, putting the first entry to the main interface at roughly twenty seconds. The comparison table adds that a plugin already on local disk loads in under 500ms against more than 1500ms elsewhere, and that the first download to home screen takes under a second. These are the project's own numbers on its own setup.

A comparison table with one competitor in it

The README sets the framework against Shadow in a table, which is unusual in a plugin project and worth reading closely for what it claims. On plugin packaging size the table puts the other framework at above 3M against about 500k here. On download management and version control, the other framework is listed as requiring your own implementation, while this one is described as one step. On loading logic the paths differ, host to manager to plugin against host to plugin. On the timing rows, first download to home screen is 3 to 5 seconds or more against under a second, and local load is over 1500ms against under 500ms. The rows that matter most for architecture are the last four: fully dynamic support, dynamic framework code, dynamic download logic and dynamic version control are all listed as unsupported in the other column, alongside plugin debugging and Compose. Whatever you think of the framing, it is a clear statement of what the project believes it uniquely provides.

What the framework actually supports

The supported feature list is the practical contract, and it is broad. All four Android components are covered, Activity, Service, ContentProvider and Broadcaster, and a plugin Service can be used across processes. Fragments are supported, as are assets, and a plugin can access host classes. Plugins may be independent of one another or may have dependencies on each other, which is what allows a segmented load where several APKs are loaded separately or in dependency order. A single app can be split into modules that load separately, and a single Activity can hold Views loaded from several APKs. The notification bar, So loading, plugin debugging and Compose are all listed as supported. The repository layout reflects the split, with a WX/ directory for the framework and a WX-Resource/ directory for images, plus the Gradle files, a gradlew wrapper and a settings.gradle.

Running the sample, and the server you inherit

There is no package manager step and no install command in the documentation. The sample can be run by scanning a QR code to install it, or by pulling the code, opening the empty shell host project and running the sample. Either way the host is an empty shell, because all the plugins live on a server address the author configured. The documentation says you can swap the plugins for your own, and the whole point of the project is that the environment is fully dynamic, including the plugin download logic, the version management and the download server address, so that swap is a configuration exercise rather than a code change. The sample instructions also carry a repeated warning not to capture packets or set a proxy, which is a reasonable request for a project whose sample app downloads and runs code at runtime. For your own team the equivalent warning is about your own store: a server that pushes code to devices is infrastructure you have to own and secure.

Where a plugin framework like this beats and loses to a plain release

The realistic alternative is the ordinary one, ship a new version of the app through the store. The difference in approach is where the update decision lives. With a store release, the change is versioned, reviewed, staged, and rolled back as a unit, and users get it when the store delivers it. With a plugin architecture, a module can be replaced on the device without a store submission, which is why such frameworks exist and why teams with regulated release processes or slow store review use them. The cost is that the host is now a loader rather than an application, and every feature it can run is code arriving from outside the store review process. A middle path exists, and the framework supports it, which is to keep most of the app in the host and push only the parts that must change, so the blast radius of a compromised or broken plugin server is limited to the modules it serves.

Editorial conclusion

WXDynamicPlugin fits an Android team that must ship feature changes without an app store release and that already operates its own download server, and it fits teams that want to debug plugin code as ordinary project modules rather than as dynamically loaded artefacts. It does not fit a project that needs an established, widely reviewed plugin ecosystem, and it does not fit a team unwilling to run a plugin distribution backend, because the framework deliberately makes the download and version control logic itself replaceable by plugins. Verify first that the plugin loading approach works with your build and packaging setup, that you can host and sign plugin artefacts yourself, and that the claimed plugin sizes and load times hold on your own devices before you commit to the architecture.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. wgllss/WXDynamicPlugin on GitHub