Status Update
Comments
ub...@gmail.com <ub...@gmail.com> #2
The first CL of this effort has been officially submitted in lifecycle-common
.
ub...@gmail.com <ub...@gmail.com> #3
Branch: androidx-main
commit e4a654d863af22d2a4f486b90cf29c26c487cffb
Author: Ivan Matkov <ivan.matkov@jetbrains.com>
Date: Mon Jan 22 11:49:53 2024
Multiplatform support for lifecycle-runtime
This change introduces multiplatform support for the lifecycle-runtime module by exposing the `LifecycleRegistry` to common, ensuring compatibility with published versions on Android.
BUG: 317249252
Relnote: Added multiplatform support for `lifecycle-runtime`
Test: Run existing and newly added tests
Change-Id: I0c5acfde52bd6c4a3cf7f38193c235915b45d549
M lifecycle/lifecycle-runtime/build.gradle
M lifecycle/lifecycle-runtime/src/androidInstrumentedTest/kotlin/androidx/lifecycle/MissingClassTest.kt
M lifecycle/lifecycle-runtime/src/androidInstrumentedTest/kotlin/androidx/lifecycle/ViewTreeLifecycleOwnerTest.kt
M lifecycle/lifecycle-runtime/src/androidMain/baseline-prof.txt
M lifecycle/lifecycle-runtime/src/androidMain/java/androidx/lifecycle/LifecycleRegistryOwner.java
A lifecycle/lifecycle-runtime/src/androidMain/kotlin/androidx/lifecycle/LifecycleRegistry.android.kt
M lifecycle/lifecycle-runtime/src/androidMain/kotlin/androidx/lifecycle/ReportFragment.android.kt
M lifecycle/lifecycle-runtime/src/androidMain/kotlin/androidx/lifecycle/ViewTreeLifecycleOwner.android.kt
M lifecycle/lifecycle-runtime/src/androidMain/res/values/ids.xml
M lifecycle/lifecycle-runtime/src/androidUnitTest/kotlin/NoPackageObserver.kt
M lifecycle/lifecycle-runtime/src/androidUnitTest/kotlin/NoPackageTest.kt
M lifecycle/lifecycle-runtime/src/androidUnitTest/kotlin/androidx/lifecycle/LifecycleRegistryTest.java
A lifecycle/lifecycle-runtime/src/commonMain/kotlin/androidx/lifecycle/LifecycleRegistry.kt
A lifecycle/lifecycle-runtime/src/commonTest/kotlin/androidx/lifecycle/CommonLifecycleRegistryTest.kt
A lifecycle/lifecycle-runtime/src/commonTest/kotlin/androidx/lifecycle/TestObserver.kt
A lifecycle/lifecycle-runtime/src/desktopMain/kotlin/androidx/lifecycle/LifecycleRegistry.desktop.kt
M lifecycle/lifecycle-runtime/src/jvmMain/kotlin/androidx/lifecycle/LifecycleRegistry.jvm.kt
M lifecycle/lifecycle-runtime/src/nativeMain/kotlin/androidx/lifecycle/LifecycleRegistry.native.kt
A lifecycle/lifecycle-runtime/src/nativeTest/kotlin/androidx/lifecycle/NativeLifecycleRegistryTest.kt
M settings.gradle
ub...@gmail.com <ub...@gmail.com> #4
The second CL of this effort has been officially submitted in aosp/2927699, adding multiplatform support to lifecycle-runtime
.
da...@google.com <da...@google.com> #5
Branch: androidx-main
commit 08f40110a0400fa434ed023e763152e6f4aa39af
Author: Ivan Matkov <ivan.matkov@jetbrains.com>
Date: Fri Jan 26 17:06:51 2024
Multiplatform support for lifecycle-runtime-ktx
BUG: 317249252
Relnote: Added multiplatform support for `lifecycle-runtime-ktx`
Test: Run existing tests
Change-Id: If445d68e7e85929839ad10347b31b9f11d61c00d
M lifecycle/lifecycle-runtime-ktx/build.gradle
M lifecycle/lifecycle-runtime-ktx/src/androidInstrumentedTest/kotlin/androidx/lifecycle/Expectations.kt
M lifecycle/lifecycle-runtime-ktx/src/androidInstrumentedTest/kotlin/androidx/lifecycle/FakeLifecycleOwner.kt
M lifecycle/lifecycle-runtime-ktx/src/androidInstrumentedTest/kotlin/androidx/lifecycle/FlowWithLifecycleTest.kt
M lifecycle/lifecycle-runtime-ktx/src/androidInstrumentedTest/kotlin/androidx/lifecycle/LaunchWhenTest.kt
M lifecycle/lifecycle-runtime-ktx/src/androidInstrumentedTest/kotlin/androidx/lifecycle/PausingDispatcherTest.kt
M lifecycle/lifecycle-runtime-ktx/src/androidInstrumentedTest/kotlin/androidx/lifecycle/RepeatOnLifecycleTest.kt
M lifecycle/lifecycle-runtime-ktx/src/androidInstrumentedTest/kotlin/androidx/lifecycle/TaskTracker.kt
M lifecycle/lifecycle-runtime-ktx/src/androidInstrumentedTest/kotlin/androidx/lifecycle/TrackedExecutor.kt
M lifecycle/lifecycle-runtime-ktx/src/androidInstrumentedTest/kotlin/androidx/lifecycle/ViewTreeLifecycleOwnerTest.kt
M lifecycle/lifecycle-runtime-ktx/src/androidInstrumentedTest/kotlin/androidx/lifecycle/WithLifecycleStateTest.kt
M lifecycle/lifecycle-runtime-ktx/src/androidMain/AndroidManifest.xml
M lifecycle/lifecycle-runtime-ktx/src/androidMain/kotlin/androidx/lifecycle/View.android.kt
M lifecycle/lifecycle-runtime-ktx/src/commonMain/kotlin/androidx/lifecycle/FlowExt.kt
M lifecycle/lifecycle-runtime-ktx/src/commonMain/kotlin/androidx/lifecycle/RepeatOnLifecycle.kt
M lifecycle/lifecycle-runtime-ktx/src/commonMain/kotlin/androidx/lifecycle/WithLifecycleState.kt
M settings.gradle
ub...@gmail.com <ub...@gmail.com> #6
Branch: androidx-main
commit d48a756bfcbc4679bbcf641554f75be5458cad04
Author: Ivan Matkov <ivan.matkov@jetbrains.com>
Date: Mon Mar 04 22:55:59 2024
Align source sets in lifecycle-runtime with JetBrains fork
- Move shared code into `nonJvmMain` (a common source set for native and web targets)
- Use expect/actual for `WeakReference` and `isMainThread`
Bug: 317249252
Test: N/A
Change-Id: If70f6aa691d231674a7e3234a668e4b8184f2d91
M development/build_log_simplifier/messages.ignore
M lifecycle/lifecycle-runtime/build.gradle
M lifecycle/lifecycle-runtime/src/nativeMain/kotlin/androidx/lifecycle/LifecycleRegistry.native.kt
A lifecycle/lifecycle-runtime/src/nativeMain/kotlin/androidx/lifecycle/WeakReference.native.kt
A lifecycle/lifecycle-runtime/src/nonJvmMain/kotlin/androidx/lifecycle/LifecycleRegistry.nonJvm.kt
A lifecycle/lifecycle-runtime/src/nonJvmMain/kotlin/androidx/lifecycle/WeakReference.nonJvm.kt
ub...@gmail.com <ub...@gmail.com> #7
Branch: androidx-main
commit 1b02695fac60c198985910d0a4658a3f53027f35
Author: Ivan Matkov <ivan.matkov@jetbrains.com>
Date: Mon Mar 04 22:08:16 2024
Align source sets in lifecycle-common with JetBrains fork
- Move shared code into `nonJvmMain` (a common source set for native and web targets)
Bug: 317249252
Test: N/A
Change-Id: If7e05abc26e53d93f1b853941687602093576cc5
M lifecycle/lifecycle-common/build.gradle
M lifecycle/lifecycle-common/src/nonJvmMain/kotlin/androidx/lifecycle/Lifecycle.nonJvm.kt
M lifecycle/lifecycle-common/src/nonJvmMain/kotlin/androidx/lifecycle/Lifecycling.nonJvm.kt
da...@google.com <da...@google.com> #8
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.lifecycle:lifecycle-common:2.8.0-alpha03
androidx.lifecycle:lifecycle-common-iosarm64:2.8.0-alpha03
androidx.lifecycle:lifecycle-common-iossimulatorarm64:2.8.0-alpha03
androidx.lifecycle:lifecycle-common-iosx64:2.8.0-alpha03
androidx.lifecycle:lifecycle-common-jvm:2.8.0-alpha03
androidx.lifecycle:lifecycle-common-linuxx64:2.8.0-alpha03
androidx.lifecycle:lifecycle-common-macosarm64:2.8.0-alpha03
androidx.lifecycle:lifecycle-common-macosx64:2.8.0-alpha03
androidx.lifecycle:lifecycle-runtime:2.8.0-alpha03
androidx.lifecycle:lifecycle-runtime-android:2.8.0-alpha03
androidx.lifecycle:lifecycle-runtime-desktop:2.8.0-alpha03
androidx.lifecycle:lifecycle-runtime-iosarm64:2.8.0-alpha03
androidx.lifecycle:lifecycle-runtime-iossimulatorarm64:2.8.0-alpha03
androidx.lifecycle:lifecycle-runtime-iosx64:2.8.0-alpha03
androidx.lifecycle:lifecycle-runtime-linuxx64:2.8.0-alpha03
androidx.lifecycle:lifecycle-runtime-macosarm64:2.8.0-alpha03
androidx.lifecycle:lifecycle-runtime-macosx64:2.8.0-alpha03
ub...@gmail.com <ub...@gmail.com> #9
yb...@google.com <yb...@google.com> #10
just to clarify on #8, we cannot count the number of invalidation events as database might combine them. Instead, we need to make sure latest value is always eventually dispatched.
ub...@gmail.com <ub...@gmail.com> #11
As it's an intermittent problem (triggered by specific transaction timing), it's difficult to surface in the first place, so this type of instrumented test cannot really reliably find the problem, it was hard enough trying to surface it with manually run code in a controlled environment. Also, the longer of a time interval we choose, the harder it gets to reproduce within a finite amount of time.
I think the main concern with fixing the issue is not actually the PR's ability to address the issue, but the potential to introduce regressions. I have no idea why there was no transactionality for the TRUNCATE path, was it really just because the thinking was that it was superfluous? This can only be addressed by existing test coverage and maybe insight from whoever wrote the original code and other knowledegable team members. I traced its history and found no helpful pointers, I remember finding that it always looked like this since it was introduced in the early days of Room.
Do you guys really want the sketchy black box test, or maybe just stick with some extra code documentation, existing regression tests, plus the repro case? It almost seems not worth the trouble.
yb...@google.com <yb...@google.com> #12
Seems like it was added here:
For testing, I agree it is not great as it only shows as a flake but we have a couple tests stress similar to that and we usually use 10secs (to account for cloud devices). Under normal circumstances (device is not slowed down and db is not locked), it shouldn't take more than ~100ms to get the update after the right (usually much faster). But with virtual device testing, we cannot rely on timing hence we pick large enough numbers (if a virtual device idles for 10 seconds, than that is an infra problem).
It is at least better than nothing and if it flakes, that'll keep bugging us until finding a better solution.
Btw, if you can detect the exact ordering of events that will cause the problem, then we can add package private restricted APIs from the InvalidationTracker to have fine tuned control over them in tests.
ub...@gmail.com <ub...@gmail.com> #13
da...@google.com <da...@google.com> #14
oh-oh, I'm sorry to hear that, we definitely don't require you to enter any SSH key password. If anything, only the built-in Git integration in Android Studio will ask you for Github credentials if you use it to push changes to Github. Maybe you have some additional plugin that is asking for it? The Github-based setup downloads the correct Android Studio version needed for the project, but some plugins are installed separately and can persist across IDE installations.
yb...@google.com <yb...@google.com> #15
#13 i'm curious what went wrong w/ the Github setup. I don't want to hijack this bug but if you can either file an issue at
el...@google.com <el...@google.com>
ub...@gmail.com <ub...@gmail.com> #16
I don't think I will add the test; ultimately I am unfamiliar with AOSP tooling and in particular the test setup for this, so it's an open-ended time commitment, and I already spent too much time on this tiny code problem.
I can still make a PR for the code change that fixes the bug (based on my testing via repro & actual app), but it's so trivial that you might just as well change it yourselves. As I mentioned in #10, the primary concern with the code change would be regressions, which are not captured by the envisioned test anyway, so I'd consider it defensible to go without test. The alternative, no fix, leaves TRUNCATE in a poor state.
ub...@gmail.com <ub...@gmail.com> #17
I meant
yb...@google.com <yb...@google.com> #18
are you still blocked on the SSH issue? FYI we do have other people sending PRs from Github without that issue so I would like to figure out what is broken in your case (as it might be affecting other people as well).
I want to respect your time though so if you don't want to deal with it anymore, you can send a PR without tests and we'll take it from there to add tests (though unfortunately, we cannot merge a PR without tests so we'll need to add them).
ub...@gmail.com <ub...@gmail.com> #19
Thanks for your and Aurimas' help on the SSH issue last year, doing a checkout with filter and SSH caused the problems. I suggested updating the online instructions to point out this gotcha, not sure what happened after that on your end.
I am sending you a PR with the fix & added test. I gave it one more push to get if off my mind.
el...@google.com <el...@google.com>
ap...@google.com <ap...@google.com> #20
Branch: androidx-main
commit a5c2900ca26e8f24d4492e5a0e90f0669702c680
Author: Uli Bubenheimer <bubenheimer@users.noreply.github.com>
Date: Mon Apr 19 09:22:25 2021
[GH] Fix intermittent InvalidationTracker issues in JournalMode.TRUNCATE
## Proposed Changes
- Fixes issue in Room JournalMode.TRUNCATE where the InvalidationTracker callback is sometimes invoked invalidly, too late, or not at all.
- Adds InvalidationTrackerBehavioralTest
## Testing
Test: ./gradlew test connectedCheck -x :room:room-benchmark:cC -x :room:integration-tests:room-incremental-annotation-processing:test
## Issues Fixed
Fixes:
This is an imported pull request from
Resolves #159
Github-Pr-Head-Sha: b32fc85dd1368db5fe046b1edfecdb82ac3e5478
GitOrigin-RevId: 169da50d9ce5d0be6aa686d603d51a380f46ab63
Change-Id: I0c04f25303043f45c8efe687df93f7122acbc7d4
A room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/InvalidationTrackerBehavioralTest.java
M room/runtime/src/main/java/androidx/room/InvalidationTracker.java
Description
Component used: Room InvalidationTracker
Version used: 2.2.5
Devices/Android versions reproduced on: Android Studio emulator with Android R DP 2.1
Sample project:https://github.com/bubenheimer/invalidationtrackerbug
I am seeing consistency problems with the updates from InvalidationTracker when using JournalMode.TRUNCATE.
In my production app some updates are skipped - the observer is never called for a percentage of updates to a rarely updated table, causing the associated app screen to not get updated to the current state. I debugged into it and believe that this is associated with a lack of transactionality in InvalidationTracker.mRefreshRunnable. JournalMode.WRITE_AHEAD_LOGGING uses a transaction here, while JournalMode.TRUNCATE does not. Reads and writes of the table update log are disassociated, leaving the door open to overwriting recent changes to the log.
In the provided sample project I see the opposite effect, however: a lot of extra updates are triggered by InvalidationTracker with JournalMode.TRUNCATE. I am not sure what the underlying mechanism is for this behavior.
Exact effects are timing-related. The bottom line is that InvalidationTracker looks essentially broken for JournalMode.TRUNCATE. On the other hand I do not see significant issues with JournalMode.WRITE_AHEAD_LOGGING.