How We Pluginized a Game SDK for Hundreds of Android Apps

Yuewen Game SDK Feature Overview

The Yuewen Game SDK provides third‑party games with account and payment integration, as well as operational features such as events, messages, gifts, and customer service.

Background of Pluginization Requirements

Traditional game SDK release processes involve excessive repetitive work. The simplified SDK integration and packaging flow requires (N+M·N)·K repetitions, where N is the number of games per developer, M the number of cooperating developers, and K the number of SDK releases. This scaling cost contradicts modern internet principles, prompting the need for a streamlined process.

Preliminary Research on Pluginization Technology

Since the SDK must be usable across various build tools (Eclipse, Android Studio, apktool, etc.) and its entry class may not be an Android component, the pluginized SDK must retain the same API as the original. Core pluginization functions include class identification, resource identification, and Android component identification.

Class identification: custom ClassLoader merging host and plugin dex/zip/libpath, or modifying the system ClassLoader.

Resource identification: separating host and plugin resources or merging them with packageId grouping via custom aapt, public.xml fixes, or Gradle hooks.

Android component identification: tricks to make plugin components appear to have system lifecycle, e.g., pre‑embedding components into the host manifest or using placeholder registration and runtime hooking.

Summary of Core Pluginization Techniques

Practical Pluginization of Game SDK

Low‑frequency component updates allow pre‑embedding placeholders for future extensions.

Resource independence is costly; we adopted a custom aapt approach for stable, low‑cost resource ID handling.

Custom DexClassLoader merges host and plugin classes.

Static proxies replace Application, Activity classes and resources.

Initial deployment on a few games helped stabilize compatibility. Early issues included crashes on Android 7.0+ due to a custom ClassLoader inheriting from ClassLoader; switching to DexClassLoader resolved the problem.

Testing revealed that certain APIs (e.g., addContentView) behaved differently in Unity3D games, requiring offline replacement of built‑in plugins via apktool and re‑signing for online testing.

What Pluginization Brought Us

After pluginization, the SDK achieves one‑time integration across games, drastically reducing repetitive work. The repeat count becomes (N+N·M) plus gray‑scale testing cycles.

Testing SDK Directly in Production

We can test new SDK versions online without publishing them. For example, a new feature using addContentView was tested by downloading multiple games, replacing the built‑in plugin with apktool, and observing that Unity3D engines blocked the view events. This early detection allowed us to devise alternative solutions before gray‑scale rollout.