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_us
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.

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>
Merged-In: Ic8afc2eb054717018d227263a93d9fcc25bfa180
Change-Id: Ic8afc2eb054717018d227263a93d9fcc25bfa180

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

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