Fix thread priorities for unstarted threads.
Calls to Thread.setPriority for unstarted threads now behave
similar to dalvik. Note that there's still some inconsistent
behaviour carried over from dalvik.
- high priority threads from bg_non_interactive processes are
not always moved to the SP_FOREGROUND cgroup.
- we do not attempt to adjust the cgroup of a native thread
that's attaching.
Note that on android, the system_server will change the
cgroups for all running threads in a process when it moves
into the foreground and background. It's by design that
threads in a background process can request to be moved
to the foreground by setting a higher priority.
bug: 17893086
(cherry picked from commit 1bd326a5e2aaff06a5bcae9cb2c42a4e8de31401)
Change-Id: Iad362f7c5c8697c349f2b6d7fcba69a4e141883e
diff --git a/runtime/thread_android.cc b/runtime/thread_android.cc
index 73a9e54..d5db983 100644
--- a/runtime/thread_android.cc
+++ b/runtime/thread_android.cc
@@ -55,6 +55,13 @@
int newNice = kNiceValues[newPriority-1];
pid_t tid = GetTid();
+ // TODO: b/18249098 The code below is broken. It uses getpriority() as a proxy for whether a
+ // thread is already in the SP_FOREGROUND cgroup. This is not necessarily true for background
+ // processes, where all threads are in the SP_BACKGROUND cgroup. This means that callers will
+ // have to call setPriority twice to do what they want :
+ //
+ // Thread.setPriority(Thread.MIN_PRIORITY); // no-op wrt to cgroups
+ // Thread.setPriority(Thread.MAX_PRIORITY); // will actually change cgroups.
if (newNice >= ANDROID_PRIORITY_BACKGROUND) {
set_sched_policy(tid, SP_BACKGROUND);
} else if (getpriority(PRIO_PROCESS, tid) >= ANDROID_PRIORITY_BACKGROUND) {