Opening Custom Process Activities in RePlugin: Process Mapping and Launch Flow

RePlugin is an open‑source Android plugin framework that allows a host app to load and run components from plugin APKs. This guide focuses on opening an Activity that runs in a plugin‑defined custom process.

Because the host does not recognize the plugin’s custom process tags, the first step is to make the host aware of them by mapping each custom process to one of three pre‑allocated placeholder processes (:p0, :p1, :p2) defined in the host.

During plugin loading, RePlugin reads the plugin’s AndroidManifest.xml to collect the android:process attributes of the four major components (Activity, Service, Provider, Receiver). It obtains a PackageInfo object with:

PackageInfo packageInfo = PackageManager.getPackageArchiveInfo(path);

The collected component information is stored in a ComponentList data structure:

class ComponentList {

final HashMap mActivities = new HashMap<>();

final HashMap mProvidersByName = new HashMap<>();

final HashMap mServices = new HashMap<>();

final HashMap mReceivers = new HashMap<>();

}

RePlugin can generate the process‑mapping table in two ways:

Static mapping : developers add a <meta-data android:name="process_map" android:value="[{'from':'com.qihoo360.replugin.sample.demo1:bg','to':':p0'}]"/> entry to the plugin’s manifest.

Dynamic mapping : at runtime the plugin’s custom‑process count is taken modulo the number of host placeholder processes to select a target (e.g., int processIndex = customProcessCount % hostProcessCount; ), and the corresponding placeholder name ( :p0 , :p1 , or :p2 ) is used.

After the mapping table is built, RePlugin adjusts the processName field of each component in ComponentList using helper methods such as:

adjust(HashMap processMap, activityMap);

adjust(HashMap processMap, serviceMap);

adjust(HashMap processMap, providerMap);

adjust(HashMap processMap, receiverMap);

During the host build, Gradle injects three Provider components ( ProcessPitProviderP0 , ProcessPitProviderP1 , ProcessPitProviderP2 ) with android:process=":p0" (or ":p1", ":p2"). To start a placeholder process, the host calls:

getContentResolver().insert(ProcessPitProviderP0Uri, values);

This triggers the provider’s synchronization mechanism, waking the target process.

The article then walks through the Android system flow that follows:

ActivityThread#attach() creates the Application instance.

installContentProviders() registers all providers with the ActivityManagerService (AMS).

AMS creates a ProcessRecord , assigns a PID, and launches the process.

The host’s custom ClassLoader loads the plugin’s classes, and Application#attachBaseContext() and Application#onCreate() are invoked.

Process recycling is handled by a periodic task that checks whether the placeholder process has any active activities, services, or binders; if none are present, the process self‑terminates. To avoid accidental termination when multiple plugins share a placeholder, byte‑code instrumentation (ASM, Javassist, AspectJ) can replace calls to System.exit() or android.os.Process.killProcess(pid) with custom logic that respects a reference counter.

Finally, the guide details the launch sequence for an Activity in a custom process:

Call RePlugin.startActivity() from host or plugin.

The plugin manager assigns a target placeholder process.

The target process is started synchronously.

A Binder call allocates an Activity slot in the target process.

The slot information is returned to the caller.

The caller passes the slot (with its custom process tag) to AMS.

AMS launches the Activity; the host’s modified ClassLoader redirects the load to the plugin’s ClassLoader, allowing an “uninstalled” Activity to run.

The article concludes that with these steps, RePlugin can transparently open Activities that belong to plugin‑defined independent processes, and future articles will cover related ClassLoader, Resources, Layout handling, and slot‑allocation algorithms.