Key Issues and Solutions in Implementing the Aura Android Plugin Framework

Overview: This article explains the key problems solved by the Aura plugin framework for Android and how addressing them enables building a generic plugin architecture.

Key points to implement a plugin framework include:

Existence forms of the four main plugin components such as Activity.

Class loading and access within plugins.

Resource loading and access.

Inter‑calls between host and plugins, and between plugins.

Resource sharing between host and plugins.

Final plugin packaging and integration into the host project.

Existence forms of Activity and other components

The approaches are divided into two streams: the proxy stream (using a proxy Activity in the host to manage plugin Activity lifecycles, or managing lifecycles via reflection or interfaces) and the direct declaration stream (declaring plugin components directly in the host’s AndroidManifest.xml). The latter was chosen for Aura.

Class loading and access

Aura creates a dedicated ClassLoader for each plugin, inheriting from ClassLoader and overriding findClass() to follow the parent‑delegation model, with the host’s BootClassLoader as the parent. All plugin ClassLoaders are centrally managed.

How plugins and classes are loaded

Define a DeleggateClassLoader that replaces the original loader in ActivityThread.loadedApk at application start.

When a class from a plugin is requested, DeleggateClassLoader.findClass() consults an index file to locate the owning plugin, loads the plugin, and then loads the class with that plugin’s ClassLoader.

Resource loading and access

Android resource IDs consist of PackageId, TypeId, and EntryId. Aura modifies the plugin’s PackageId to a safe range (0x21‑0x7E) to avoid conflicts with the host. After a plugin is loaded, its path is added to the system AssetManager, allowing normal resource access. Version‑specific adaptations are required.

Inter‑calls between host and plugins

An index file records classes that need to be exposed (activities, services, fragments, etc.). The index can be generated at runtime or during host compilation; Aura uses the latter for better performance. Classes listed in the index must be kept from obfuscation.

Resource sharing between host and plugins

Shared libraries (network, image, logging, analytics) must be accessible to both sides. Aura provides two solutions: modifying aapt to align resource IDs, or using a Gradle plugin to rewrite class and resource IDs without touching aapt. Aura adopts the Gradle‑plugin approach.

Final plugin packaging

Plugins are built as APKs and must be bundled into the host APK. Two methods exist: placing the APK in the host’s assets directory and installing it at runtime, or renaming the APK to lib<name>.so and placing it in libs/armeabi . Aura chooses the latter for faster installation.

In summary, the article outlines the major challenges Aura addresses to realize an Android plugin framework, laying the groundwork for future detailed discussions.