WaEnhancer Xの仕組みとWhatsAppフックをPure Javaで書き直す理由

公式WhatsAppクライアントを使用するのは奇妙な体験です。Messengerは執拗なMeta AIを追加し続け、便利な設定を削除し、メディアの閲覧を制限していきます。以前は、愛好家がWhatsApp Plusのような第三方変更で这些问题を解決していましたが、Metaは改変APKファイルを実行するとすぐにアカウントをバンします。Androidでは、LSPosedフレームワークを使用してRAM内で直接アプリの動作を変更するという别の道があります。

GitHubでWaEnhancer Xリポジトリを見つけました。元のWaEnhancerプロジェクトのフォークで、興味深いエンジニアリング方針を採用しています。元のモジュールの作者がコードをKotlinで書き直し、設定を外部画面に移动し始めたとき、WaEnhancer Xの開発者は一歩引いてPure Javaに戻り、WhatsAppインターフェースに直接ネイティブ統合を行いました。

内部構造：AIブロッキングから直接SQLite操作まで

モジュールの主なタスクは、元のWhatsAppクライアント内のメソッド呼び出しを傍受し、そのロジックを変更することです。技術的な観点から、これがどのように行われるか、いくつかの例を示します：

• 迷惑なUIの破棄。WhatsAppはサーバーフラグを通じてMeta AIバナーを常に押し付けようとします。WaEnhancer XはこれらのUI要素の作成を傍受し、画面にレンダリングされる前にステータスView.GONEを強制的に設定します。
• UIアニメーションを待たずに直接SQLクエリを実行。ステータスやメッセージを削除すると、標準クライアントは一連のアニメーションとダイアログを実行します。モジュールはこのレイヤーをバイパスし、ローカルSQLiteデータベースmessageとファイルストレージにMediaProviderを通じて直接アクセスし、操作を即座に実行します。
• 時間制限のバイパス。ワンタイムメディアファイル（View Once）はスクリーンショットとリプレイ表示をブロックします。アプリコード内のフックがアクセスフラグを substituし、表示を永続的にし、ファイルをギャラリーに保存できるようにします。
• Tasker統合。モジュールは第三方自動化ツールからAndroid Intentを受け取ることができ、位置情報やスケジュールに基づいたプライバシーモードの自動化を可能にします。

アーキテクチャのテクニック：GPLとプロプライエタリコードをどのように組み合わせるか

リポジトリで最も興味深い部分は、モジュール構造とライセンスに隠されています。プロジェクトは厳密に3つの独立したコンポーネントに分割されています：

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

なぜこのような複雑さが必要なのでしょう？GNU GPL v3の条項に違反しないようにするためです。メインのフックモジュール（:app）はGPL-3.0の下で配布されています。クローズドコンポーネントと一緒にコンパイルすると、ライセンス違反になります。

作者はすべての相互作用インターフェースをパーミッシブなApache-2.0ライセンスの下で別モジュール:apiに移動しました。実行時に、オープンなホストはContentProviderを通じて補助APKを検出し、独自のClassLoader経由で動的にロードします。その結果、クローズドプラグインはGPLライセンスされたホストコードとの直接的なバイナリ依存関係を持たずに、インターフェース:apiを通じてWhatsAppプロセス内で実行されます。

なぜKotlinではなく100% Javaなのか

現代のAndroid開発は事実上完全にKotlinに移行しましたが、XposedモジュールにとってはJavaにはまだ利点があります。低レベルのリフレクション（FeatureLoader）を常に操作する場合、Pure Javaはいくつかの利点を提供します：

1. 予測可能なバイトコード。Kotlinコンパイラの魔法（インライン関数、合成メソッド、メタデータ生成）がないことで、フックのデバッグが簡素化されます。
2. オーバーヘッドゼロ。Kotlin Standard LibraryはWhatsAppプロセスにロードされないため、WhatsApp自体が異なるライブラリのバージョンを使用している場合のバージョン衝突のリスクが軽減されます。
3. アップデート時の安定性。WhatsAppのクラス構造が新しいリリースで変更された場合、メソッド傍受アプローチはより少ない頻度で壊れます。

モジュールの設定画面もJetpack Composeでは構築されていません。開発者は標準的なPreferenceFragmentCompatを使用し、モジュールメニューをWhatsApp自体の設定に直接埋め込みました。ネイティブのアプリセクションのように見え、便利なナビゲーションのために、ローカライズされた文字列を使用してトグルをインデックス化し、目的の機能を検索するクラスFeatureCatalogが記述されました。

デバイスでモジュールを試す方法

WaEnhancer Xを実行するには、準備されたスマートフォンが必要です：

1. デバイスにはRootアクセスとLSPosedがインストールされている必要があります（ZygiskまたはRiruバージョン）。
2. GitHubリポジトリから完成したAPKをダウンロードしてインストールします。
3. LSPosed Managerアプリを開き、WaEnhancer Xモジュールをアクティブにします。
4. アプリケーションリスト（Scope）でWhatsApp」を選択します。
5. システムメニューからWhatsAppを停止（「停止」/強制停止）し、Messengerを再度起動します。

その後、WhatsAppの設定にモジュールオプションの新しいセクションが表示されます。

プロジェクトをフォローする理由

WaEnhancer Xは、Androidアドオンを作成する際にライセンス制限をバイパスするのに適切なモジュール分離がどのように役立つかの明確な例です。このプロジェクトは、リフレクション、LSPosedフックアーキテクチャ、第三方アプリケーションへのコードインジェクションを学習している開発者にとって役立ちます。

コードの基本部分はオープンで、外部トラッカーがなく、疑わしい第三方ビルドを作成せずにクローズドMessengerの動作を変更する方法を示しています。