Status Update
No update yet.
Comments
ub...@gmail.com
ub...@gmail.com
Logs after follow mentioned steps in
===============================================
V/TAG: ViewModelFirst Created
2) Can you please provide the below requested information to better understand the issue:
Android build
Which Android build are you using? (e.g. KVT49L)
Device used
Which device did you use to reproduce this issue?
Please provide sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.
ub...@gmail.com
da...@google.com
I have this problem on all my devices. Here are some of them:
1. Samsung Galaxy S9 (SM-G960F)
Android: 8.0.0 build: R16NW.G960FXXU1BRE5
2. Pixel2
Android: 9 build: PPP3.180510.008
3. Galaxy A3 (SM-A320FL)
Android: 7.0 build: NRD90M.A320FLXXS2BRAA
The three attachments included are: The built apk, the source code and a video displaying the issue.
The video showcases the app running on Galaxy S9 (Phone 1) with the following order:
1. Set "Don't keep activities" to enabled.
2. Happy case when everything is correct and onCleared() is called.
3. Fault case when the home button is pushed and onCleared() __is not called__.
ub...@gmail.com
Fragments currently use the fact that the system called onSaveInstanceState() as a marker on whether the Activity could be recreated. "Don't keep activities" specifically breaks that assumption by saving the instance state, then immediately throwing it away.
In a typical system, the only time that saved instance state would be thrown away would be if your process is being destroyed, of which there is no callback (either to your app or to ViewModels). Therefore this bug is limited to only devices using "Don't keep activities".
Saved state is an imperfect signal here, so we'll switch to the correct signal - Activity.isChangingConfigurations().
ub...@gmail.com
da...@google.com
ub...@gmail.com
yb...@google.com
ub...@gmail.com
?
Can you reproduce it there? If you can, it shouldn't be closed. If you can't maybe it should be closed too.
yb...@google.com
ub...@gmail.com
da...@google.com
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
#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
ub...@gmail.com
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
I meant
yb...@google.com
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
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
ap...@google.com
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.