Android P Restrictions, App Bundles, and the Evolution of JD’s Plugin Architecture

Android P introduces a strict ban on private (non‑SDK) APIs, forcing developers of large‑scale apps to reconsider existing plugin solutions. The article reviews the three‑tiered gray‑list policy (shallow‑gray, deep‑gray, blacklist), the impact on target SDK 28, and the migration window provided by Google.

Google’s official dynamic delivery framework, Android App Bundles (AAB), was unveiled at Google IO 2018. AAB splits an app into a Base APK, configuration APKs, and dynamic‑feature APKs, allowing Google Play to deliver only the resources matching a device’s configuration, thereby reducing download size. The article details the internal structure of AAB, the overall workflow from build to delivery, and lists its advantages, limitations, and integration costs (Android Studio 3.2, Play Core Library, SplitCompat for pre‑Android 6.0, etc.).

Despite the benefits of AAB, many Chinese developers still rely on plugin frameworks to address issues such as the 65 536 method limit, multi‑team parallel development, and rapid iteration. The article outlines common “black‑tech” techniques used in plugin systems: hooking critical Android components, custom class‑loader strategies, and reflective resource loading (e.g., AssetManager.addAssetPaths). It also shows a scan of JD’s Aura plugin framework revealing usage of shallow‑gray APIs.

JD’s roadmap aims to phase out the legacy Aura plugin framework in favor of a hybrid AuraPlus solution that blends componentization with plugin capabilities. The new architecture removes the monolithic JdLib, adopts a “everything is a component” model, and introduces a multi‑module, multi‑project build structure where each component produces an Api.jar and a Full.aar. Dependency rules are enforced to keep component relationships explicit and interface‑driven.

Key technical pillars of the redesign include high cohesion with low coupling, project‑level isolation using Gradle modules, a flexible component‑communication mechanism (API jar + Full.aar), and a lightweight SDK layer that aggregates common base components without re‑introducing the heavyweight JdLib. Additional best practices such as resource‑prefixing, a unified third‑party library bundle (ThirdBundle), and a BaseResBundle for shared resources are also described.

Overall, the article provides a comprehensive guide for Android developers facing Android P’s API restrictions, encourages early adoption of Android App Bundles, and presents JD’s concrete steps toward a more modular, maintainable, and future‑proof mobile architecture.