Fixed
Status Update
No update yet.
Comments
ap...@google.com
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
ap...@google.com
ap...@google.com
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 (
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
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit e73f03b20876839876da2621d7f43d3e99083d67
Author: Sergey Vasilinetc <sergeyv@google.com>
Date: Mon Nov 13 15:04:51 2023
Multiprocess support for constraints with networkRequest
bug: 280634452
Test: ParcelableConstraintConvertersTest
Change-Id: I00638cd2b5cd9a6061d54a4292fc038bc08eb34a
M work/work-multiprocess/src/androidTest/java/androidx/work/multiprocess/ParcelableConstraintConvertersTest.kt
M work/work-multiprocess/src/main/java/androidx/work/multiprocess/parcelable/ParcelableConstraints.java
M work/work-runtime/src/main/java/androidx/work/impl/utils/NetworkRequestCompat.kt
https://android-review.googlesource.com/2827515
Branch: androidx-main
commit e73f03b20876839876da2621d7f43d3e99083d67
Author: Sergey Vasilinetc <sergeyv@google.com>
Date: Mon Nov 13 15:04:51 2023
Multiprocess support for constraints with networkRequest
bug: 280634452
Test: ParcelableConstraintConvertersTest
Change-Id: I00638cd2b5cd9a6061d54a4292fc038bc08eb34a
M work/work-multiprocess/src/androidTest/java/androidx/work/multiprocess/ParcelableConstraintConvertersTest.kt
M work/work-multiprocess/src/main/java/androidx/work/multiprocess/parcelable/ParcelableConstraints.java
M work/work-runtime/src/main/java/androidx/work/impl/utils/NetworkRequestCompat.kt
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 8e58edb325897499550949ba4bbd51fa5e4f935d
Author: Sergey Vasilinetc <sergeyv@google.com>
Date: Mon Nov 13 15:42:00 2023
Throw from the Constaints.Builder if NetworkRequest with NetworkSpecifier is passed
bug: 280634452
Test: ConstraintsTest
Change-Id: I1e6fffd4e5bbdf074c43a974b177dc123e55b54b
A work/work-runtime/src/androidTest/java/androidx/work/ConstraintsTest.kt
M work/work-runtime/src/main/java/androidx/work/Constraints.kt
M work/work-runtime/src/main/java/androidx/work/impl/utils/NetworkRequestCompat.kt
https://android-review.googlesource.com/2827691
Branch: androidx-main
commit 8e58edb325897499550949ba4bbd51fa5e4f935d
Author: Sergey Vasilinetc <sergeyv@google.com>
Date: Mon Nov 13 15:42:00 2023
Throw from the Constaints.Builder if NetworkRequest with NetworkSpecifier is passed
bug: 280634452
Test: ConstraintsTest
Change-Id: I1e6fffd4e5bbdf074c43a974b177dc123e55b54b
A work/work-runtime/src/androidTest/java/androidx/work/ConstraintsTest.kt
M work/work-runtime/src/main/java/androidx/work/Constraints.kt
M work/work-runtime/src/main/java/androidx/work/impl/utils/NetworkRequestCompat.kt
se...@google.com
Will be released in 2.10.0-alpha01
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.work:work-multiprocess:2.10.0-alpha01androidx.work:work-runtime:2.10.0-alpha01
Description
Version used: 2.8.1
Devices/Android versions reproduced on: Android 10, 13
Our app uses both JobScheduler (in older part) and WorkManager (in newer code)
We noticed that jobs and workers never start on Android 11 and 13 devices connected to a private network (no internet access).
Older devices (Android 8) work fine.
It seems to be related to JobInfo.setRequiredNetworkType creating a NetworkRequest with NET_CAPABILITY_INTERNET and NET_CAPABILITY_VALIDATED.
On the JobScheduler side we fixed the problem by specifying the required network with a proper NetworkRequest instead of a networkType.
Unfortunately this is not possible with the WorkManager.
I believe that private networks are quite common in enterprise environment. The WorkManager is currently not suitable for this use case.
More generally it would be nice to be able define the required network more precisely.
In our case, the workaround we can think of are :
- Modify the URL used to validate the network (via OEM config), so that the devices believe they have internet access. It work but it's ugly and only possible for some devices.
- Migrate the code from WorkManager to JobScheduler. Interestingly enough we were previously considering the opposite.