Status Update
Comments
ly...@gmail.com <ly...@gmail.com> #2
From the other issue:
note that it is never the right approach to attach a
<deeplink>
to an<activity>
destination as that will never give you the right behavior when using anon another app's task (where the system back should immediately take the user back to the app that triggered your deep link). Instead, you should attach your deep link directly to your second activity (either by manually writing the appropriate implicit deep link <intent-filter>
or by adding the<deeplink>
to the start destination of a nav host in that second activity).
A lint error saying as such when a <deepLink>
element is added in Navigation XML would go a really long way to avoiding this case. Our navigation-runtime-lint
artifact that would contain this check.
da...@google.com <da...@google.com> #3
We have some
ly...@gmail.com <ly...@gmail.com> #5
Branch: androidx-main
commit cd77b4bbe312dd8892dfbb3c662344d13a96c82d
Author: Julia McClellan <juliamcclellan@google.com>
Date: Thu Apr 14 15:31:46 2022
Deep link in activity destination in navigation lint
Test: Included tests of API version and the lint rule
Bug: 178403185
Change-Id: Ic15a5ec165620b7ef5b3f03538cc83b5576add8d
A navigation/navigation-runtime-lint/src/main/java/androidx/navigation/runtime/lint/DeepLinkInActivityDestinationDetector.kt
A navigation/navigation-runtime-lint/src/test/java/androidx/navigation/runtime/lint/ApiLintVersionsTest.kt
M settings.gradle
A navigation/navigation-runtime-lint/build.gradle
M navigation/navigation-runtime/build.gradle
A navigation/navigation-runtime-lint/src/main/java/androidx/navigation/runtime/lint/NavigationRuntimeIssueRegistry.kt
A navigation/navigation-runtime-lint/src/test/java/androidx/navigation/runtime/lint/DeepLinkInActivityDestinationDetectorTest.kt
A navigation/navigation-runtime-lint/src/main/resources/META-INF/services/com.android.tools.lint.client.api.IssueRegistry
da...@google.com <da...@google.com> #6
An update: I agree this is a big behavior change and for compatibility reasons we want to continue having Room blocking DAO functions and API be uninterruptible. We are trying to work on a solution for this.
ap...@google.com <ap...@google.com> #7
Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <
Link:
Use Coroutines RxJava builders in RxRoom
Expand for full commit details
Use Coroutines RxJava builders in RxRoom
The coroutines-rxjava builders have better handling for cancellation and allows Room to use Coroutine internals more natively which in turns avoids performBlocking.
Bug: 400584611
Test: RxJava2Test and RxJava3Test
Change-Id: I639162c82584eea358d061d0e2c48ce0f260a47c
Files:
- M
room/integration-tests/kotlintestapp/src/androidTest/java/androidx/room/integration/kotlintestapp/test/DeferredBooksDaoTest.kt
- M
room/integration-tests/kotlintestapp/src/androidTest/java/androidx/room/integration/kotlintestapp/test/RxJava2QueryTest.kt
- M
room/integration-tests/kotlintestapp/src/androidTest/java/androidx/room/integration/kotlintestapp/test/UpsertTest.kt
- M
room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/RxJava2Test.java
- M
room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/RxJava3Test.java
- M
room/room-rxjava2/src/main/java/androidx/room/RxRoom.kt
- M
room/room-rxjava3/src/main/java/androidx/room/rxjava3/RxRoom.kt
Hash: 52899e0b7ab58364d7467f39dfee82cc3dc2c04d
Date: Wed Mar 12 11:38:37 2025
ap...@google.com <ap...@google.com> #8
Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <
Link:
Use an uninterruptible version of runBlocking
Expand for full commit details
Use an uninterruptible version of runBlocking
As part of Room KMP the internals in Room were migrated to Coroutines and for compatibility reasons blocking functions (APIs and generated code) where migrated to use a bridge that relied on runBlocking. This introduced a behaviour change where if the thread that called runBlocking was interrupted, then runBlocking would throw an InterruptedException. The behaviour in general is not bad since it means work is abandoned faster but it breaks behaviour compatibility as Room never threw this exception before.
To not break existing application and expectations this change adds a runBlockingUninterruptible to be used in Room's bridge that works like runBlocking but ignores thread interruption.
Bug: 342709652
Bug: 400584611
Test: RunBlockingUninterruptibleTest
Change-Id: Ib591225477829e77b51e65a14556d6caddc62222
Files:
- A
room/integration-tests/kotlintestapp/src/androidTest/java/androidx/room/integration/kotlintestapp/test/InterruptionTest.kt
- A
room/room-runtime/src/androidInstrumentedTest/kotlin/androidx/room/coroutines/RunBlockingUninterruptibleTest.kt
- M
room/room-runtime/src/androidMain/kotlin/androidx/room/InvalidationTracker.android.kt
- M
room/room-runtime/src/androidMain/kotlin/androidx/room/RoomDatabase.android.kt
- A
room/room-runtime/src/androidMain/kotlin/androidx/room/coroutines/RunBlockingUninterruptible.android.kt
- M
room/room-runtime/src/androidMain/kotlin/androidx/room/util/DBUtil.android.kt
Hash: e20fec969cc938655537f87624a6f45e942c370d
Date: Thu Mar 13 10:37:44 2025
Description
Component used:room
Version used:2.7.0-rc01
Exception
PS, please don't reference my email in comment