IssueTracker

Trying to reproduce this on my 4.2.2 (v17) Nexus 4. Added this drawable:

<transition xmlns:android="http://schemas.android.com/apk/res/android" >
    <item android:drawable="@drawable/test_drawable_blue"/>
    <item android:drawable="@drawable/test_drawable_green"/>
</transition>

where blue/green drawables look like this:

<shape
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:shape="rectangle">
    <size
        android:width="@dimen/drawable_large_size"
        android:height="@dimen/drawable_small_size" />
    <solid
        android:color="@color/test_blue" />
</shape>

Then added this test:

    @Test
    public void testMutateTransitionDrawable() {
        Drawable drawable = ResourcesCompat.getDrawable(mResources,
                R.drawable.test_transition_drawable, null);
        assertTrue(drawable instanceof TransitionDrawable);

        Drawable mutated = drawable.mutate();
        assertTrue(drawable instanceof TransitionDrawable);
        assertTrue(mutated instanceof TransitionDrawable);
    }

It passes on the device. Going to also try on other earlier devices a bit later in the day once they are charged.

Also not reproducible on Galaxy Nexus running 4.0.1 (v14), 4.0.4 (v15) and 4.2.2 (v17)

https://android-review.googlesource.com/c/platform/frameworks/support/+/960032 with the test. Closing as not reproducible. If this is still happening for you, we'd need to see either a test (same as in this CL) or a small, standalone sample project that reproduces this issue on v17 (or other) devices.

Project: platform/frameworks/support
Branch: androidx-main

commit 1de6215c6bd9e887e3d94556e9ac55cfb7b8c797
Author: Chet Haase <chet@google.com>
Date:   Fri Aug 26 16:56:05 2022

    Fix cpuDuration calculation and expose totalDuration
   
    A missing metric (the time taken to queue the data sync to RenderThread)
    in FrameMetrics made the cpuDuration data in JankStats less accurate than
    it could be, and made it harder to determine the equivalent of
    "totalDuration" in comparison to data one could get from FrameMetrics.
    Further complicating the problem was the overlap of SWAP duration
    in the calculation of both GPU and CPU durations on API31, making it
    even trickier to align all of these similar-yet-different metrics.
   
    There was a request (see the bug) to expose totalDuration for JankStats
    overall, but this is problematic since it is not possible to expose it
    consistently across different releases (on 31 it includes GPU, on 24 it
    does not, and on 16 it has even less data behind it). Instead of
    exposing it overall, we now expose it just in API31, in the
    FrameDataApi31 structure, where iut has all of the data it needs to
    provide an accurate measure of total duration.
   
    Bug: 243694893
    Test: Ran JankStats on API24 and 31
    RelNote: cpuDuration now more accurate, also new totalDuration on API31
    Change-Id: I59ce8c67f06a168f96893375c8aeca5516a55d81

M       metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi31Impl.kt
M       metrics/metrics-performance/api/public_plus_experimental_current.txt
M       metrics/metrics-performance/api/restricted_current.txt
M       metrics/metrics-performance/src/main/java/androidx/metrics/performance/FrameDataApi31.kt
M       metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi24Impl.kt
M       metrics/metrics-performance/src/androidTest/java/androidx/metrics/performance/test/JankStatsTest.kt
M       metrics/metrics-performance/api/current.txt

https://android-review.googlesource.com/2199726

Thanks for the quick fix!!! We believe the take away is the following:

> use frameDurationCpuNanos to replace FrameMetrics.TOTAL_DURATION on API versions 24-30, then use frameDurationTotalNanos on version 31+

I do have a follow-up question: while looking at the following trace (https://developer.android.com/static/studio/images/profile/jank_detection-frame-lifecycle-threads.png), I am wondering if "the sheer delta between draws in main thread" is a good rough representation of how much the user perceived as a frame's rendering time or the delta still misses some execution time on the render thread in parallel to the main thread.

I don't know off-hand from looking at that trace (since it's just a big blank area), but yeah, we don't have visibility pre-FrameMetrics in where the time was going. The perceived time between draws is still a decent overall metric, because that will end up being visible to the user (jank == longer delays between draws). So it's not like a huge delay in GPU rendering (for example) would end up being masked by the fact that we couldn't detect it due to the lack of FrameMetrics data. I'm not certain it would show up on that exact frame, however; I wonder if some GPU delays would show up on later frames, when that later frame went to send data to the GPU and had to wait to send it down, or was able to send it, but it just queued up waiting for the GPU to finish doing all of those earlier operations. Regardless, it's all decent data (I believe) in terms of knowing when there are general frame performance problems, it's just a little harder to diagnose where in the pipeline those problems occurred.

That's great to hear since we are taking a high level experimental approach to test frame render optimizations or investigate regressions. We often look at the aggregated frame drop or render data between the experimental groups. The "draw interval" measurement so far fits our needs and is indeed quite sensitive to the changes too.