Status Update
No update yet.
Comments
al...@google.com
<transition xmlns: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="
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.
ap...@google.com
pe...@google.com
pe...@google.com
+Sayed as he wants to use this for WebView Prefetch API.
el...@google.com
Thanks Peter!
Based on libraryversions.tomlandroidx.core:core has a separate module for launch, but it seems to be released with androidx.core group?
al...@google.com
It's a non-atomic group, so the contained artifacts are versioned (mostly) separately. We version and release the core artifact with core-ktx and core-testing.
Whats the process for rolling out changes to
androidx.core:core?
Make the changes, then either request a release on go/jetpad or let me know when you want a release. Generally speaking, core releases whenever contributors (or dependent libraries) need it released. If you need this to go to stable soon, you can file a bug against the core component along the lines of "Release core 1.x.0 to stable" and I'll churn through the process of beta/rc/stable.
pe...@google.com
We have some experimental APIs that could do with using this interface. As they're experimental, to not block the library from otherwise progressing through the release train, I assume we need these changes to be in stable?
Filed
Description
See API council conversation here:https://chat.google.com/room/AAAATnZMo34/VJnRMh_50Z8
For Java APIs in AndroidX, there isn't a standard way to deliver an async result that could fail. For Kotlin you'd use a
suspend fun(which can throw) and for Java APIs in the platform you'd use anFor context, we (
androidx.webkit) are designing an API that would benefit from being able to useOutcomeReceiverand we'd prefer to use a standard approach rather than writing our own.I assume that
androidx.core.oswould be the right place for this to live.