How WaEnhancer X Works and Why Rewrite WhatsApp Hooks in Pure Java

Using the official WhatsApp client is a peculiar experience. The messenger keeps accumulating intrusive Meta AI, losing convenient settings, or restricting media viewing. Previously, enthusiasts solved such problems with third-party modifications like WhatsApp Plus, but Meta quickly bans accounts for running modified APK files. On Android, there's another path: modifying the app's behavior directly in RAM using the LSPosed framework.

On GitHub, I came across the WaEnhancer X repository. It's a fork of the original WaEnhancer project, following an interesting engineering path. When the original module's authors started rewriting code in Kotlin and moving settings to external screens, the WaEnhancer X developer took a step back to pure Java and native integration directly into the WhatsApp interface.

What's Inside: from Blocking AI to Direct SQLite Work

The main task of the module is to intercept method calls inside the original WhatsApp client and change their logic. Here are several examples of how this is done from a technical perspective:

• Destroying intrusive UI. WhatsApp constantly tries to push Meta AI banners through server flags. WaEnhancer X intercepts the creation of these UI elements and forcibly sets them to status View.GONE before rendering on screen.
• Direct SQL queries instead of waiting UI animations. When you delete a status or message, the standard client runs a chain of animations and dialogs. The module bypasses this layer and accesses the local SQLite database message and file storage through MediaProvider directly, executing the operation instantly.
• Bypassing time restrictions. One-time media files (View Once) block screenshots and replay viewing. A hook in the app code substitutes access flags, making viewing permanent and allowing the file to be saved to the gallery.
• Tasker integration. The module can receive Android Intents from third-party automation tools, enabling privacy mode automation based on location or schedule.

Architectural Tricks: How to Combine GPL and Proprietary Code

The most interesting part of the repository is hidden in the module structure and licensing. The project is strictly divided into three independent components:

+-------------------------------------------------------+
|                   Helper Plugin APK                   |
|           (Закрытый код / Дополнительные фичи)        |
+-------------------------------------------------------+
                           |
                           v  (Compile-Time Dependency)
+-------------------------------------------------------+
|                     :api Module                       |
|          Лицензия Apache-2.0 / Интерфейсы и DTO       |
+-------------------------------------------------------+
                           ^
                           |  (Shared API Dependency)
+-------------------------------------------------------+
|                     :app Module                       |
|           Лицензия GPL-3.0 / Основной фреймворк       |
+-------------------------------------------------------+

Why is such complexity needed? To avoid violating the GNU GPL v3 terms. The main hooks module (:app) is distributed under GPL-3.0. If compiled together with closed components, it would result in a license violation.

The author moved all interaction interfaces into a separate module :api under the permissive Apache-2.0 license. During runtime, the open host detects the auxiliary APK through ContentProvider and dynamically loads it via its own ClassLoader. As a result, the closed plugin executes inside the WhatsApp process through interfaces :api, without having direct binary dependencies with the GPL-licensed host code.

Why 100% Java Instead of Kotlin

Modern Android development has almost completely moved to Kotlin, but for Xposed modules, Java still has its advantages. When constantly working with low-level reflection (FeatureLoader), pure Java provides several benefits:

1. Predictable bytecode. The absence of Kotlin compiler magic (inline functions, synthetic methods, and metadata generation) simplifies hook debugging.
2. Zero overhead. The Kotlin Standard Library is not loaded into the WhatsApp process, which reduces the risk of version conflicts if WhatsApp itself uses different library versions.
3. Stability across updates. The method interception approach breaks less often when WhatsApp's class structure changes with a new release.

The module's settings screen wasn't built with Jetpack Compose either. The developer used standard PreferenceFragmentCompat, embedding the module menu directly into WhatsApp's own settings. It looks like a native app section, and for convenient navigation, a class FeatureCatalog was written that indexes toggles and searches for the desired feature using localized strings.

How to Try the Module on Your Device

Running WaEnhancer X requires a prepared smartphone:

1. The device must have Root access and LSPosed installed (Zygisk or Riru version).
2. Download the ready-made APK from the GitHub repository and install it.
3. Open the LSPosed Manager app and activate the WaEnhancer X module.
4. In the applications list (Scope), select WhatsApp.
5. Stop WhatsApp through the system menu ("Stop" / Force Stop) and launch the messenger again.

After that, a new section with module options will appear in WhatsApp settings.

Why Follow the Project

WaEnhancer X is a clear example of how proper module separation helps bypass license restrictions when creating Android add-ons. The project will be useful for developers studying reflection, LSPosed hook architecture, and code injection into third-party applications.

The base part of the code is open, free of external trackers, and clearly demonstrates how to modify a closed messenger's behavior without creating questionable third-party builds.