Fixed
Status Update
Comments
jb...@google.com <jb...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
https://android-review.googlesource.com/1123258
https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
[Deleted User] <[Deleted User]> #3
[Deleted User] <[Deleted User]> #4
Project: platform/frameworks/support
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically ( b/140759491 ).
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
https://android-review.googlesource.com/1288456
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
an...@gmail.com <an...@gmail.com> #5
Also check a screenshot please
[Deleted User] <[Deleted User]> #6
jb...@google.com <jb...@google.com> #7
The way Dynamic Navigation has to handle activities is inherently different from other destinations so not returning there could possibly be intentional.
Is this something new that was caused by upgrading to 2.5.0? Or was it pre-existing?
[Deleted User] <[Deleted User]> #8
It is caused by upgrading from 2.3.0 to 2.5.0.
When we saw this issue we did a rollback to 2.3.5.
2.3.5 - the last version where this issue doesn't exist
When we saw this issue we did a rollback to 2.3.5.
2.3.5 - the last version where this issue doesn't exist
[Deleted User] <[Deleted User]> #9
and in 2.3.5 you do have a return statement there
jb...@google.com <jb...@google.com> #10
You're right, looks like we didn't add it back when we made
an...@gmail.com <an...@gmail.com> #11
I n what version we can expect to get it back?
[Deleted User] <[Deleted User]> #12
any news? :)
be...@google.com <be...@google.com> #13
The statement was removed during the migration to V2, when we did not expect this problem to occur.
[Deleted User] <[Deleted User]> #14
Can you give an ETA please of the fix?
[Deleted User] <[Deleted User]> #15
any news? :)
fo...@gmail.com <fo...@gmail.com> #16
Hi there, I face the same issue. Any progress so far?
pa...@outlook.com <pa...@outlook.com> #17
Hey!
Same issue in my project. Any update here?
Same issue in my project. Any update here?
ap...@google.com <ap...@google.com> #18
Project: platform/frameworks/support
Branch: androidx-main
commit 0c4ad1856d1b956d8a0da8074557a5a69fb130d9
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Aug 30 16:16:49 2022
Fix navigating to Activities from unloaded modules
Currently, if you are using dynamic Navigation and you attempt to
navigate to a Activity in a module that has not yet be loaded, a
ClassNotFoundException is thrown. This is because the
DynamicActivityNavigator currently attempts to install the module (which
is an async operation) and then immediately navigates to the new class.
Instead, we should return after the install attempt and then allow the
systme to retry the navigation at the appropriate time.
RelNote: "Dynamic Navigation now properly attempts to install Activity
destinations from other modules before navigating to them."
Test: tested on a device using bundletool
Bug: 240292838
Change-Id: Ia2c1645426d2f6a5958a10379a99f2aade3dd03a
M navigation/navigation-dynamic-features-runtime/src/main/java/androidx/navigation/dynamicfeatures/DynamicActivityNavigator.kt
https://android-review.googlesource.com/2199792
Branch: androidx-main
commit 0c4ad1856d1b956d8a0da8074557a5a69fb130d9
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Aug 30 16:16:49 2022
Fix navigating to Activities from unloaded modules
Currently, if you are using dynamic Navigation and you attempt to
navigate to a Activity in a module that has not yet be loaded, a
ClassNotFoundException is thrown. This is because the
DynamicActivityNavigator currently attempts to install the module (which
is an async operation) and then immediately navigates to the new class.
Instead, we should return after the install attempt and then allow the
systme to retry the navigation at the appropriate time.
RelNote: "Dynamic Navigation now properly attempts to install Activity
destinations from other modules before navigating to them."
Test: tested on a device using bundletool
Bug: 240292838
Change-Id: Ia2c1645426d2f6a5958a10379a99f2aade3dd03a
M navigation/navigation-dynamic-features-runtime/src/main/java/androidx/navigation/dynamicfeatures/DynamicActivityNavigator.kt
jb...@google.com <jb...@google.com> #19
This has been fixed internally and will be released in Navigation 2.5.2
and 2.6.0-alpha01
.
na...@google.com <na...@google.com> #20
This bug was linked in a change in the following release(s):
androidx.navigation:navigation-dynamic-features-runtime:2.6.0-alpha01
androidx.navigation:navigation-dynamic-features-runtime:2.5.2
Description
Version used: 2.5.0
Devices/Android versions reproduced on: all
package androidx.navigation.dynamicfeatures
public class DynamicActivityNavigator
return statement is missing here after install manager call.
It causes application to crash because you're navigating to not existing class yet.
Fatal Exception: java.lang.RuntimeException
Unable to instantiate activity ComponentInfo{...}: java.lang.ClassNotFoundException: Didn't find class "com....Activity" on path: DexPathList[.....]