Deep Dive into Android Application Startup: From bindApplication to Activity Launch

The article continues a previous discussion on Android Application creation, reviewing key classes and methods such as ActivityThread, ActivityManagerService, and Instrumentation. It explains that after AMS.attachApplicationLocked calls bindApplication, the process proceeds through several layers of the new ActivityTaskManagerService (ATMS) introduced in Android 10.

1. AMS.attachApplicationLocked

The method checks for isolated entry points and active instrumentation, then calls thread.bindApplication with various parameters. If normalMode is true, it invokes

mAtmInternal.attachApplication(app.getWindowProcessController())

, where mAtmInternal is an ActivityTaskManagerInternal implementation provided by ActivityTaskManagerService.LocalService.

2. ATMS.LocalService.attachApplication

This method simply forwards the call to RootActivityContainer.attachApplication, a new class in Android 10 that abstracts the former ActivityStackSupervisor logic.

3. RootActivityContainer.attachApplication

The core logic iterates over activity displays, finds the focused stack, and for each activity matching the process UID and name, calls ActivityStackSupervisor.realStartActivityLocked. If no activity matches, it ensures activities are visible.

4. ActivityStackSupervisor.realStartActivityLocked

This method creates a ClientTransaction, adds a LaunchActivityItem and a lifecycle item ( ResumeActivityItem or PauseActivityItem), then schedules the transaction via mService.getLifecycleManager().scheduleTransaction. The transaction encapsulates all callbacks needed to launch the activity.

4.1 ClientTransaction.addCallback

Adds a ClientTransactionItem to the internal callback list.

4.2 ATMS.getLifecycleManager

Returns the ClientLifecycleManager responsible for handling the transaction.

4.3 ClientLifecycleManager.scheduleTransaction

Obtains the client thread, calls transaction.schedule(), and ensures the client is a Binder before recycling.

4.4 ClientTransaction.schedule

Invokes preExecute on the handler, then sends a message EXECUTE_TRANSACTION to the client.

4.5 ActivityThread.H.handleMessage

When the message is received, the TransactionExecutor executes the transaction.

4.6 TransactionExecutor.execute

First runs all callbacks via executeCallbacks, then applies the lifecycle state via executeLifecycleState.

4.7 LaunchActivityItem.execute

Creates an ActivityClientRecord and calls client.handleLaunchActivity, which ultimately invokes ActivityThread.handleLaunchActivity.

4.8 ActivityThread.handleLaunchActivity

Initializes the window manager, hints the graphics environment, and calls performLaunchActivity to create the Activity instance.

4.9 ActivityThread.performLaunchActivity

Uses Instrumentation.newActivity to instantiate the Activity, attaches a ContextImpl, sets the theme, and calls Instrumentation.callActivityOnCreate. It also registers the activity in the activity map.

4.10 TransactionExecutor.executeLifecycleState

Executes the lifecycle item (e.g., ResumeActivityItem) which calls client.handleResumeActivity, leading to ActivityThread.performResumeActivity and eventually Activity.onStart and Activity.onResume.

5. Summary

The walkthrough demonstrates how Android 10 refactors the Application startup path: AMS delegates to ATMS, which uses new container classes and a transaction‑based mechanism to launch the first Activity. The process involves creating a ClientTransaction, populating it with launch and lifecycle callbacks, scheduling it through the ClientLifecycleManager, and finally executing the callbacks on the main thread to instantiate and resume the Activity.