This fixes a bug where the device could see a priority inversion when updating display brightness. The problem occurs because the code that manages screen brightness holds the master lock while waiting for the native method to complete. On some devices, each call can amount to tens to hundreds of ms, which meant clients using PowerManager APIs could block for the duration of the call. In some cases, the animation could block for many seconds because the unfairness of Java locks. The solution is to handle all brightness updates in a separate thread that does not hold the master lock while calling native methods. This also makes the animation more consistent by animating by actual wall clock time rather than depending on the round-trip from the driver. Change-Id: Ifad76fb2fb77e7b2a72dd9150440d87e22581b40
…
…
…
…
…
Description
No description provided
Languages
Java
77.3%
Kotlin
9.2%
PowerBuilder
6.6%
C++
5.5%
AIDL
1%