Commit 3586e921 authored Jan 28, 2021 by Riddle Hsu

Restore activityPaused to a sync binder call

The intention of previous one-way change is to reduce blocking
call on client side. But in most of cases the blocking of
activityPaused is no harm for the app. Because either the app
is going to background or it launches another activity in the
same process. If the case is the latter, the creation of next
activity is still scheduled after activityPaused is done.

Some apps may even use Idler to start some post initialization.
They assume the timing of idle will happen after the whole
consecutive launch in the same process. Then the non-blocking
call may break their assumption that the idle event is triggered
earlier.

Bug: 161781274
Bug: 178005687
Test: CtsWindowManagerDeviceTestCases
Test: In the onCreate of first activity, start the second activity
      and set an Idler on UI thread. The Idler should be called
      after the second activity is launched.

Change-Id: Ib256d0a534fedb0b39f2825f4deb2f8c81e857be

parent 8241f19a

core/java/android/app/IActivityClientController.aidl

+7 −1

Original line number	Diff line number	Diff line
		@@ -34,7 +34,13 @@ interface IActivityClientController {
		oneway void activityIdle(in IBinder token, in Configuration config, in boolean stopProfiling);
		oneway void activityResumed(in IBinder token);
		oneway void activityTopResumedStateLost();
		oneway void activityPaused(in IBinder token);
		/**
		* Notifies that the activity has completed paused. This call is not one-way because it can make
		* consecutive launch in the same process more coherent. About the order of binder call, it
		* should be fine with other one-way calls because if pause hasn't completed on the server side,
		* there won't be other lifecycle changes.
		*/
		void activityPaused(in IBinder token);
		oneway void activityStopped(in IBinder token, in Bundle state,
		in PersistableBundle persistentState, in CharSequence description);
		oneway void activityDestroyed(in IBinder token);