Ignore Developer's Settings Animation Scale in Android

My app relies heavily on animations to work, and when their speed is changed in the developer's options, the whole app breaks and stops working. I've been researching ways of ignoring the developer's settings and forcing the animations to run as they should, but it is not changing anything really.

I'm calling this function in my App's Application Class' onCreate:

private fun fixAnimation() {
    val durationScale = Settings.Global.getFloat(contentResolver, Settings.Global.ANIMATOR_DURATION_SCALE, 1f)
    Log.d("fixAnimation", "durationScale: $durationScale")
    if (durationScale != 1f) {
        try {
            ValueAnimator::class.java.getMethod("setDurationScale",Float::class.javaPrimitiveType).invoke(null, 1f)
        } catch (t: Throwable) {
            Log.e("fixAnimation", t.message ?: t.toString())
        }
    }
}

But nothing changed.

Got it from here: Make ObjectAnimator animation duration independent of global animator duration scale setting in developer options And here: https://medium.com/@arpytoth/android-objectanimator-independent-of-global-animator-duration-fe33c808c83e Apparently it is working for some people but not on my case.

Maybe it is because I am using ViewPropertyAnimator, and not ValueAnimator directly? But it should still work, as this is changing the ValueAnimator's duration scale setting globally, and ViewPropertyAnimator is backed by a ValueAnimator...

Upvotes: 1

Views: 2163

Answers (1)

ubuntudroid
ubuntudroid

Reputation: 3999

You are calling your code too early.

If you set a breakpoint into ValueAnimator.setDurationScale(float durationScale) you will notice that after your code has run WindowManagerGlobal will reset the duration scale back to the system value.

So one possible solution is to call your code in Activity.onResume(). Theoretically you could also put it in Activity.onCreate() however if the user (or the system, e.g. to save battery) then changes it while the app is backgrounded, it won't work.

There still are edge cases, e.g. if the system decides to change the factor while the app is in foreground or possibly in multi-window scenarios, but that's as good as it gets with this workaround. After all you likely don't want to check and fix this every second or so as there is reflection involved.

Upvotes: 0

Related Questions