Commit e76ef0bd authored May 03, 2023 by Tomislav Novak Committed by Jing Ji May 25, 2023

Fix setAttachingSchedGroupLSP() to support use_fifo_ui



The method added in aosp/1249555 ("Start process of next activity with
top priority in advance") to set the priority of the newly-launched top
app's UI thread doesn't handle the use_fifo_ui=1 case.

By setting mSetSchedGroup it also prevents subsequent applyOomAdjLSP()
calls from fixing the priority, so on devices with the sys.use_fifo_ui
sysprop set, main thread may not actually use SCHED_FIFO. This is an
issue mainly for the initial launch of an app -- once it's moved to
another sched group and then back, the priority is adjusted correctly.

Bug: 284355269
Test: set sys.use_fifo_ui, start a new app, and check thread priorities
      with `ps -lT <pid>`
Signed-off-by: Tomislav Novak <tnovak@meta.com>
Change-Id: Ic8afc2eb054717018d227263a93d9fcc25bfa180
Merged-In: Ic8afc2eb054717018d227263a93d9fcc25bfa180

parent 429962dd

services/core/java/com/android/server/am/OomAdjuster.java

+5 −1

Original line number	Diff line number	Diff line
		@@ -3253,7 +3253,11 @@ public class OomAdjuster {
		// {@link SCHED_GROUP_TOP_APP}. We don't check render thread because it
		// is not ready when attaching.
		app.getWindowProcessController().onTopProcChanged();
		if (mService.mUseFifoUiScheduling) {
		mService.scheduleAsFifoPriority(app.getPid(), true);
		} else {
		setThreadPriority(app.getPid(), THREAD_PRIORITY_TOP_APP_BOOST);
		}
		initialSchedGroup = SCHED_GROUP_TOP_APP;
		} catch (Exception e) {
		Slog.w(TAG, "Failed to pre-set top priority to " + app + " " + e);