Plugin Compilation and Packaging in the Aura Framework: Resource Sharing, AAPT and Gradle Aura-Plugin Solutions

The article explains how the Aura framework handles plugin compilation and packaging by managing shared resources through public.xml, assigning unique package IDs, and offering two solutions—modifying AAPT and using the Gradle aura‑plugin—to achieve small, independent Android plugin bundles.

JD Retail Technology
JD Retail Technology
JD Retail Technology
Plugin Compilation and Packaging in the Aura Framework: Resource Sharing, AAPT and Gradle Aura-Plugin Solutions

Plugin compilation and packaging is a crucial task in modular development, and the Aura framework has explored various approaches, encountering challenges especially in handling shared resources and resource grouping.

Shared Resource Sharing – Shared resources, including images, layouts, styles, and code, are placed in the host project as JAR or AAR files. Plugins can directly use them, and Aura ensures consistent resource IDs by maintaining the host's public.xml file.

Before Gradle 1.3.0, public.xml could be placed under /res/values/; after that version it must be copied to the merged build directory via a Gradle script.

Android resource IDs consist of PackageId, TypeId, and EntryId. To avoid conflicts, Aura assigns each plugin a unique PackageId in the stable range 0x21‑0x7E, while alternative EntryId manipulation is considered too complex.

The compilation goal is to reference shared resources during build but not package them, keeping the final plugin size minimal.

Two Implementation Schemes

AAPT Scheme – Modifies the Android build tool AAPT to accept a packageId parameter, provides shared resources as JAR (using provided) or AAR (extracting classes.jar), and passes public.xml to fix IDs.

Pros: Near‑native compilation stability. Cons: Requires multiple AAPT versions for different Android releases, cross‑platform builds, and manual replacement of the tool.

Gradle Aura‑Plugin Scheme – Based on the Small open‑source solution, it hooks into key Gradle tasks without modifying AAPT. It processes JAR/AAR, classes, resources, package IDs, assets, native .so files, AndroidManifest.xml, public.xml, and R.class using Gradle transforms and resource‑arsc parsing.

Advantages: Simple configuration in build.gradle, cross‑platform support, no AAPT changes. Disadvantages: Slightly lower stability due to manual interference, and the need to keep up with rapid Gradle version updates.

Conclusion – Both schemes can handle shared resources and produce small, independent plugin packages. Currently Aura uses the Gradle aura‑plugin scheme as the primary solution, with the AAPT scheme kept as a fallback.

— JD.com Mobile Technology Team

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Mobile DevelopmentAndroidpluginResource ManagementGradlebuildAAPT
JD Retail Technology
Written by

JD Retail Technology

Official platform of JD Retail Technology, delivering insightful R&D news and a deep look into the lives and work of technologists.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.