Status Update
No update yet.
Comments
ra...@google.com
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
ra...@google.com
ap...@google.com
ma...@marcardar.com
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
ra...@google.com
That is correct.
As a side note, it would be nice if android:name (in meta-data) would support local class names (e.g. android:name=".FooProcessInitializer")
We tried making that part work originally. However determining the package name is expensive during startup.
lo...@gmail.com
It could be done at compile time, with a trick similar to the ${applicationId} manifest placeholder, or right into the manifest merger, or via a generated manifest (e.g. generated via Kotlin code, possibly using DSL(s)).
ma...@marcardar.com
I don't think AppInitializer.discoverAndInitialize() is reading the metadata of a custom InitializationProvider, so the initializer needs to be declared separately.
ra...@google.com
Yes, the InitializationProvider needs to be declared per-process.
ma...@marcardar.com
Are you sure the metadata tag declared on the custom InitializationProvider is being parsed? Looking at AppInitializer.discoverAndInitialize() it looks like it's only looking at non-custom InitializationProvider
ra...@google.com
Every provider declaration will also have to declare the <meta-data> entries it cares about. Unfortunately, we cannot make the assumption that Initializers that are important for one process are important for every process.
ma...@marcardar.com
I'm seeing the opposite behaviour. Using the code shown in
ra...@google.com
Are you sub-classing InitializationProvider and defining a new entry in your AndroidManifest.xml ?
Can you also please send a sample app and logs so I can better understand what is going on.
ma...@marcardar.com
Maybe you should be passing the Initialization Class to AppInitializer.discoverAndInitialize() as an argument, so that it can query the PackageManager using that instead of InitializationProvider.class
ma...@marcardar.com
The code is literally
class FooProcessInitializationProvider : InitializationProvider()
ra...@google.com
Please send us a full sample app. That and logs will tell me whats going on.
ma...@marcardar.com
I don't have the time right now, unfortunately. I'd urge you to look carefully at InitializationProvider.
ma...@marcardar.com
I'm also getting Lint errors on release builds:
Error: Every Initializer needs to be accompanied by a corresponding <meta-data> entry in the AndroidManifest.xml file. [EnsureInitializerMetadata from startup-runtime-1.1.0]
and
Error: Missing Initializer no-arg constructor [EnsureInitializerNoArgConstr from startup-runtime-1.1.0]
However, it is giving these messages for abstract initializers, which is surely incorrect.
ub...@gmail.com
Seeing the same behavior as the other commenter, with the same setup: meta-data tags being ignored for second process provider declaration, meta-data from default process provider declaration is being used instead for second process provider. Makes the multiprocess support fairly useless. Is there a desire to actually make it work?
ch...@gmail.com
Why not use the
This attribute is not implement?
ga...@gmail.com
Mac duflicate un prods verfier aosp iD in prod
eu...@gmail.com
ha...@gmail.com
Thanks!
ra...@google.com
The release is scheduled for Jan 11, 2023. Apologies for the delay !
Description