Merge "Don't take the conductor lock for syncing vibrations." into tm-dev (5960382a) · Commits · e / os / android_frameworks_base

services/core/java/com/android/server/vibrator/StartSequentialEffectStep.java

+33 −35

Original line number	Diff line number	Diff line
		@@ -189,9 +189,8 @@ final class StartSequentialEffectStep extends Step {
		// vibrating different sets of vibrators in parallel. The manager can only prepareSynced
		// one set of vibrators at a time.
		// This property is guaranteed by there only being one thread (VibrationThread) executing
		// one Step at a time, so there's no need to hold the state lock.
		// TODO: remove the large locked block in a dedicated change.
		synchronized (conductor.mLock) {
		// one Step at a time, so there's no need to hold the state lock. Callbacks will be
		// delivered asynchronously but enqueued until the step processing is finished.
		boolean hasPrepared = false;
		boolean hasTriggered = false;
		long maxDuration = 0;
		@@ -230,7 +229,6 @@ final class StartSequentialEffectStep extends Step {
		}
		}
		}
		}

		private long startVibrating(AbstractVibratorStep step, List<Step> nextSteps) {
		nextSteps.addAll(step.play());

+3 −2

Original line number	Diff line number	Diff line
		@@ -242,8 +242,9 @@ final class VibrationThread extends Thread implements IBinder.DeathRecipient {
		}
		}
		// Only run the next vibration step if we didn't have to wait in this loop.
		// If we waited then the queue may have changed, so loop again to re-evaluate
		// the scheduling of the queue top element.
		// If we waited then the queue may have changed or the wait could have been
		// interrupted by a cancel call, so loop again to re-evaluate the scheduling of
		// the queue top element.
		if (waitMillisBeforeNextStep <= 0) {
		if (DEBUG) {
		Slog.d(TAG, "Play vibration consuming next step...");