SchedulingPolicyService: specify the beneficiary of priority boost

audioflinger needs to request priority boost on behalf of hal.
This way, a new use case is introduced for requestPriority call.

Bug: 34131400
Change-Id: I6cd0e509da2b0166ca4fce181287584179abe391
Test: check priority match between audioflinger's and hal's threads
This commit is contained in:
Mikhail Naganov
2017-02-07 10:50:21 -08:00
parent e7f68ac380
commit a0cb18dbfb
2 changed files with 5 additions and 3 deletions

View File

@@ -29,6 +29,6 @@ interface ISchedulingPolicyService {
* The thread group leader of tid must be pid.
* There may be restrictions on who can call this.
*/
int requestPriority(int pid, int tid, int prio);
int requestPriority(int pid, int tid, int prio, boolean isForApp);
}

View File

@@ -37,7 +37,9 @@ public class SchedulingPolicyService extends ISchedulingPolicyService.Stub {
public SchedulingPolicyService() {
}
public int requestPriority(int pid, int tid, int prio) {
// TODO(b/35196900) We should pass the period in time units, rather
// than a fixed priority number.
public int requestPriority(int pid, int tid, int prio, boolean isForApp) {
//Log.i(TAG, "requestPriority(pid=" + pid + ", tid=" + tid + ", prio=" + prio + ")");
// Verify that the caller uid is permitted, priority is in range,
@@ -52,7 +54,7 @@ public class SchedulingPolicyService extends ISchedulingPolicyService.Stub {
}
try {
// make good use of our CAP_SYS_NICE capability
Process.setThreadGroup(tid, Binder.getCallingPid() == pid ?
Process.setThreadGroup(tid, !isForApp ?
Process.THREAD_GROUP_AUDIO_SYS : Process.THREAD_GROUP_AUDIO_APP);
// must be in this order or it fails the schedulability constraint
Process.setThreadScheduler(tid, Process.SCHED_FIFO | Process.SCHED_RESET_ON_FORK,