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 f069d601844f0b3f02ad5be2a491cc22d62456e2
Author: Chet Haase <chet@google.com>
Date:   Tue Mar 15 16:51:14 2022

    Refine startTime value
   
    Two minor fixes to refine the time used to make the start time
    of a frame:
    - INTENDED_VSYNC_TIMESTAMP: On API 26+, this time more accurately
    represents when the frame should have started than the previous
    VSYNC_TIMESTAMP. They are usually the same, but in janky times,
    the INTENDED time can capture more detail about when things should
    have occurred, and how long they actually took.
    - current vs previous frames: The use of INTENDED_VSYNC_TIMESTAMP
    means that some frames can appear to overlap (because the system
    tried to start one frame while the previous was still being processed).
    This can lead to errors in state captures for those frames since they
    appear in multiple frames for the same point in time. To avoid that
    problem, the system now caches the previous "end" time of a frame,
    and avoids using a start time less than that value.
   
    Bug: 213245198
    Test: Passed all JankStats tests on multiple API versions
    Change-Id: I23fcc474f48619be9e0a996d1d0ac4d8e168e9e1

M       metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi31Impl.kt
M       metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi24Impl.kt
M       metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi26Impl.kt

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