Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit bc27b57b authored by Simon Bowden's avatar Simon Bowden Committed by Android (Google) Code Review
Browse files

Merge changes from topic "presubmit-am-1d523cc92d6b483ea6b09ce7e530d2fb" 

* changes:
  [automerge] Don't take the conductor lock for syncing vibrations. 2p: f609ed9f
  Don't take the conductor lock for syncing vibrations.
parents 846eab98 f1955f64

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());

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

+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...");