How RePlugin Maps and Launches Custom Plugin Processes in Android

1 Process Mapping

In RePlugin the host must first recognize a plugin's custom process before it can start or manage it. This is achieved by reserving placeholder processes (:p0, :p1, :p2) in the host and mapping the plugin's activity process to one of these slots during plugin loading.

1.1 Get PackageInfo

Use PackageManager.getPackageArchiveInfo(path) to obtain a PackageInfo object for the plugin APK without installing it.

1.2 Obtain Component List

From the PackageInfo retrieve the four component lists (activities, providers, services, receivers) and store them in a data structure:

class ComponentList {
    final HashMap<String, ActivityInfo> mActivities = new HashMap<>();
    final HashMap<String, ProviderInfo> mProvidersByName = new HashMap<>();
    final HashMap<String, ServiceInfo> mServices = new HashMap<>();
    final HashMap<String, ActivityInfo> mReceivers = new HashMap<>();
}

1.3 Generate Process Mapping Table

Two approaches are supported:

Static mapping – configure a <meta-data> entry in the plugin's AndroidManifest.xml:

<meta-data android:name="process_map" android:value="[{'from':'com.qihoo360.replugin.sample.demo1:bg','to':'$p0'}]"/>

Dynamic mapping – calculate the target host slot at runtime:

int processIndex = customProcessCount % hostProcessSlotCount;
String process = hostProcessSlots[processIndex];

1.4 Adjust Process Names

Replace the processName field of each ComponentInfo in ComponentList with the mapped host process name, so the plugin's components now reference a process the host understands.

2 Start Process

During host compilation Gradle injects three providers ( ProcessPitProviderP0, ProcessPitProviderP1, ProcessPitProviderP2) with android:process=":p0" etc. Inserting a row into the provider URI triggers the host to start the corresponding process.

The start flow includes:

ActivityThread.attach() creates the Application instance.

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

Instrumentation calls Application.onCreate().

3 Process Reclamation

Each placeholder process runs a timer every 20 seconds. If the process has no activities, services, or binders (all counts are zero), it self‑terminates. To avoid killing other plugins sharing the same slot, bytecode modification can replace calls to System.exit() and android.os.Process.killProcess(pid) with custom logic that checks a counter before actually terminating.

4 Activity After Custom Process Launch

4.1 Activity Slot Information

The host reserves a set of activity slots for each process (e.g., a slot with android:process=":p2", taskAffinity=":t3", launchMode="singleTask"). These slots are shown in the host's configuration diagrams.

4.2 Launch Process

The launch sequence is:

Call RePlugin.startActivity() from the host or plugin; the request first goes to a resident (plugin‑manager) process.

The plugin manager assigns a target process based on the mapping logic.

The target process is synchronously started using the provider mechanism.

Via Binder, the manager allocates an activity slot in the target process (the slot is not yet opened by AMS).

The slot information is returned to the caller.

The caller passes the slot (with the custom process tag) to AMS, which starts the activity.

Because the host’s ClassLoader has been patched, when AMS loads the placeholder activity class it redirects to the plugin’s actual class, allowing an uninstalled activity to run.

Future articles will cover ClassLoader, Resources, Layout handling, activity slot allocation algorithms, and other technical details.