Status Update
Comments
al...@google.com <al...@google.com> #2
Investing more in Bazel build moving forward.
ap...@google.com <ap...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-main
Author: Peter E Conn <
Link:
Add OutcomeReceiverCompat
Expand for full commit details
Add OutcomeReceiverCompat
For use in AndroidX where Android's OutcomeReceiver is not yet available.
Relnote: """Adds OutcomeReceiverCompat, a version of Android's OutcomeReceiver available
on all API levels."""
Bug: 380060342
Test: presubmit
Change-Id: Ib82652305f6dd0aab5e9598dbfc13a397ab0f367
Files:
- M
core/core/api/current.txt
- M
core/core/api/restricted_current.txt
- A
core/core/src/main/java/androidx/core/os/OutcomeReceiverCompat.java
Hash: 9f21249882539de0febf492a10656850ddaed65b
Date: Thu Nov 21 14:05:22 2024
pe...@google.com <pe...@google.com> #4
Whats the process for rolling out changes to androidx.core:core
?
pe...@google.com <pe...@google.com> #5
+Sayed as he wants to use this for WebView Prefetch API.
el...@google.com <el...@google.com> #6
Thanks Peter!
Based on libraryversions.toml
androidx.core:core
has a separate module for launch, but it seems to be released with androidx.core
group?
al...@google.com <al...@google.com> #7
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 <pe...@google.com> #8
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 OutcomeReceiver , which was added in API 31.
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 useOutcomeReceiver
and we'd prefer to use a standard approach rather than writing our own.I assume that
androidx.core.os
would be the right place for this to live.