Design and Implementation of a Multi‑Container Hot‑Update Solution for Game SDKs

Author

Luoxing – Senior Development Engineer at Bilibili.

1. Preface

From a product‑operation perspective, rapid user reach for new features while minimizing extra operational and user costs is essential. For APPs, version iteration can achieve high coverage, but for SDKs—especially game SDKs, which are B2B products—fast iteration is not feasible.

2. Background and Goals

2.1 The “Three Mountains”

Long cycle : Reaching users with a game SDK takes about a month, involving SDK development, testing, game integration, and release. Engine differences and compliance requirements further extend the timeline.

High cost : Hundreds of games integrate the Bilibili game SDK. Coordinating a version release across all games incurs huge communication and support costs, and varying native development skills increase technical effort.

Incomplete gray‑release capability : Gray releases are limited to a few games, making platform‑wide sampling difficult.

2.2 Objectives

Enable rapid feature reach.

Reduce extra costs for operations, game development, technical support, and users.

Provide full‑platform gray‑release capability to improve online stability.

Can the hot‑update mechanisms used in APPs be transferred to the SDK scenario?

3. Hot‑Update Thinking for Game SDKs

3.1 Game SDK Business Model

Game SDKs differ from typical third‑party SDKs because they target games rather than native apps. Different game engines (Unity, Cocos, UE4) require a bridge layer, and game developers often have varying native development expertise, leading to higher support effort.

Key workflow: login, payment, etc., with additional mandatory checks (e.g., anti‑addiction, real‑name verification) that must not be blocked.

All SDK UI is displayed as pop‑ups over the game scene.

3.2 Common Hot‑Update Schemes

Four major categories are used in the industry: dynamic layout, virtual runtime, business plug‑in, and Web‑container enhancement.

3.3 Business Scenario Analysis

Business is divided into three categories:

Core business : login and payment – high performance and stability required.

Additional business : password change, account upgrade – longer lifecycle, stable requirements, moderate performance sensitivity.

Display‑oriented business : events, announcements – frequent content changes, low performance demands.

3.4 Technical Selection

• Dynamic layout (native + DSL) – suitable for stable, abstractable additional business. • Web‑container enhancement – low‑cost, good for display‑oriented business. • Business plug‑in (VirtualAPK) – highest performance, best for core business, Android‑only.

Because no single solution fits all, a hybrid approach using multiple containers is proposed.

4. Solution Design

4.1 Overall Architecture

The system consists of four parts: Server, SDK, Release‑Ops system, and Quality‑Efficiency Assurance.

SDK: layered into application, protocol, container, framework, component, infrastructure, and system layers.

Server: dynamically selects and delivers products based on device, game, and user info.

Release‑Ops: handles publishing, gray‑config, performance monitoring.

Quality‑Efficiency: coding standards, automation, shared scaffolding.

4.2 Sub‑system Design

4.2.1 Dynamic Routing Protocol

Provides a Scheme‑URL based routing format (scheme, group, path, fixed parameters, custom parameters). Core interfaces: RouteMapProcessService and RouteProcessService .

4.2.2 Multi‑Container

Plugin Container – based on VirtualAPK (classloader merging, resource merging, reference removal). Supports all four Android components (Activity, Service, BroadcastReceiver, ContentProvider) with high compatibility and low intrusion. Updated for Android 11, AndroidX, Gradle‑plugin, resource loading, and component support.

Dynamic Template Container – native + DSL using FlexboxLayout. DSL (JSON) describes view hierarchy; server delivers templates; client parses, caches, and renders using basic widgets (ImageView, TextView, Button, EditText).

Generic Web Container – high‑customizable WebView with theme, layout, and JsBridge capabilities (login state, network, analytics, device info, navigation, bidirectional interaction).

4.2.3 Release System

Implemented with Jenkins for automated builds. Release flow includes gray configuration (user‑ or device‑based buckets), filter configuration (SDK version, game, channel, ROM, network, device), and exclusion configuration (fallback for compatibility issues). Enables fine‑grained rollout from 0.1 % to 100 %.

5. Practice

5.1 Business‑Side Trials

Plugin container applied to login, real‑name verification, anti‑addiction, floating ball features.

Dynamic template container used for account‑related pages (password change, recovery).

Web container used for user agreements, privacy policies, and game announcements.

5.2 Release Results

Plugin download success rate: 97.24 % (mostly network issues). Installation success rate: 99.99 %. Emergency rollback tests showed immediate drop to zero in download/installation metrics, confirming rollback effectiveness.

6. Pitfalls

• R8 compatibility: mapping.txt duplication can break applymapping; solution – use higher‑version R8 and preprocess mapping files. • Obfuscation handling: SDK delivered as AAR is obfuscated once; games may re‑obfuscate, causing class name mismatches. Recommended to generate ProGuard rules after SDK obfuscation to protect SDK APIs from further shrinking.

7. Future Development

• Build a comprehensive monitoring and alert system for automatic notification, degradation, and rollback. • Leverage big data and user tags for personalized dynamic delivery.

8. Conclusion

The proposed multi‑container hot‑update solution for game SDKs, anchored by a dynamic routing protocol, achieves rapid feature reach, cost reduction, and full‑platform gray‑release capability. While there is room for optimization, the current results meet expectations.