Android Four Major Components Communication Process and Interaction with ActivityManagerService

The article explains the communication mechanisms of Android's four major components (Activity, Service, BroadcastReceiver, ContentProvider) and how they interact with the ActivityManagerService (AMS) using Binder-based inter‑process communication (IPC).

Four‑Component Basics

All four components rely on a Context object to invoke AMS functions. The article shows diagrams illustrating the flow from a Context to AMS and highlights the central role of Context in Android.

Activity ↔ AMS Interaction

An Activity starts another activity via Context.startActivity(intent) . The call stack traverses Activity.startActivity → ActivityTaskManager.getService().startActivity . AMS receives the request, checks the target process, and uses the IApplicationThread callback ( scheduleTransaction ) to deliver lifecycle events back to the app process. The callback is handled on the main thread, invoking onCreate , onResume , etc.

public static void start(Context context) {
    Intent intent = new Intent(context, AMSTargetActivity.class);
    context.startActivity(intent);
}

Service ↔ AMS Interaction

Starting a service follows a similar path: Context.startService(intent) → ActivityManager.getService().startService . AMS creates the service instance via scheduleCreateService and then calls scheduleServiceArgs to deliver onStartCommand . Both callbacks are posted to the main thread, which is why long‑running work must be off‑loaded from a service.

public static void startService(Context context) {
    Intent intent = new Intent(context, AMSTargetService.class);
    context.startService(intent);
}

Binding a Service

When a client binds to a remote service, AMS first creates the service (if needed) and then invokes scheduleBindService . The client receives the IBinder through ServiceConnection.onServiceConnected . The article details the IPC steps for cross‑process binding.

Broadcast ↔ AMS Interaction

Two registration methods are covered:

Static registration via AndroidManifest.xml results in AMS calling IApplicationThread.scheduleReceiver , which creates a new BroadcastReceiver instance on each broadcast.

Dynamic registration uses registerReceiver , which builds an IIntentReceiver (implemented by BroadcastReceiver.Transport ) and registers it with AMS. The received broadcast is posted to the main thread via Handler before invoking onReceive .

// Static registration example in AndroidManifest.xml

ContentProvider ↔ AMS Interaction

ContentProviders are declared in the manifest and instantiated during application startup. AMS stores a ContentProviderHolder that contains a ContentProvider.Transport (a Binder implementation). When a client calls ContentResolver.insert(uri, values) , the lookup chain is:

ContentResolver → ApplicationContentResolver → ActivityThread.acquireProvider → ActivityManager.getService().getContentProvider

If the provider is in the same process, it is returned directly; otherwise AMS returns a remote IContentProvider proxy.

Data‑change notifications are handled by ContentObserver . The observer is wrapped in ContentObserver.Transport (an AIDL interface) and registered with ContentService . When the provider calls notifyChange , ContentService invokes the remote observer’s onChange , which finally runs on the thread specified by the handler supplied during registration.

// Registering a content observer
Handler handler = new Handler();
Uri uri = Uri.parse("content://" + AMSTargetProvider.AUTHORITY + "/ams");
getContentResolver().registerContentObserver(uri, false, new ContentObserver(handler) {
    @Override
    public void onChange(boolean selfChange) {
        super.onChange(selfChange);
        // handle change
    }
});

Conclusion

The article concludes that understanding the IPC flow between the four components and AMS clarifies where lifecycle callbacks occur, why they run on the main thread, and how to correctly use services, broadcasts, and content providers across processes.