IssueTracker

I haven't looks on repro yet, but there is no such thing as AlwaysOnLifecycle in latest versions, LiveData has strong references on all observers (including that were added as observeForever). If nothings keeps a livedata, then it is gced.

ah I see: in observe with Lifecycle we add LiveData as observer to Lifecycle and it keeps it alive. However keeping observerforever + livedata, when nothing has reference on them, is a memory leak by definition: user can't clean this memory anyhow, because neither observer / livedata could be referenced.

It is true, though from usage perspective, it is not obvious at all.

e.g. you are in a class, like a singleton repository where you want to observe the database for some query.
and you write:

MyRepository(dao : MyDao) {
   dao.someLiveData().observeForever(....do something...);
}

And it suddenly stops working :/ which is very non-obvious from the developer's perspective.

If we kept the lifecycle in memory as long as it has observers, wouldn't it solve the problem since they can break the chain by calling stopObserving(observer) ?
When they use observeForever, they are already responsible to remove the observer so I think it is fine?

well, the issue is: no reference on observer, you can't break the chain because you don't have a reference. If you have a reference, LiveData (unfortunately) wouldn't be gc-ed, because even AlwaysActiveObserver inrenally has strong reference on livedata.

It turns out I had an app with the exact above use case: a singleton repository observing a database. The code was working properly with arch components 1.0.0 but unpredictably with 1.1.0. I think this is a good example of a leaky abstraction.
Since I want to observe the database forever with no intention to remove the observer at any point, I had no reason to keep a reference to the LiveData and it ended up being GCed along with the observers in it.
You could also argue that the problem is not with LiveData but with Room using weak references to observers but the developer is not supposed to know the Room implementation details.

I think the real problem is that LiveData has no callback to know that no one wants it anymore; like onReset in Loader.

So there's 2 options for database observers:
1. It either has to un-register observer in onInactive and on next onActive re-query db. Problematic is if nothing has changed you have to filter values or dispatch unnecessarily, and you'll pay the price of query which could be expensive.
2. Register weak observer, or have wear ref to LiveData

Room uses option 2. I created my own LiveData and I used the same (https://bitbucket.org/snippets/Boza-s6/xe8749/sample-livedata-with-features-like-loaders#EmailContentLiveData.java-104), because it was obvious solution, but now I see it will not work in every possible case.

I think there should be statically referenced Lifecycle object to which LiveData subscribes when using observeForever() (and observer is anonymous class, maybe?).

I ran into the same problem yesterday. It tooked me hours to understand what is happening and why my observeForever-observer suddenly stopped being invoked.
I think it is a really bad design that someone should know the implementation details of generated Room DB Code.

I want to use observerForever the same way like i use the simple observe and dont want to ran into problems because of internal implementation details.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit bab31cacd4ae98057b694f6ae4c781f5f25ee0c9
Author: Yigit Boyar <yboyar@google.com>
Date:   Wed Oct 31 23:41:00 2018

    Fix live data observe forever in room
   
    This CL fixes a problem where if DAO returned LiveData is
    observed with observeForever but there are no references
    to the LiveData, it would eventually be garbage collected.
   
    To avoid this, InvalidationTracker now manages these LiveData
    objects and strongly references them as long as there is an
    active observer.
    To be 100%, we should actually do it when LiveData has observers
    but right now that API does not exist in the LiveData side
    to get notified when the observer count changes 0 and 1.
   
    I've also cleaned up some test code to avoid duplicating the
    test observers in each test.
   
    I've also added an integration test that uses room w/o any of
    the optional dependencies to ensure that we don't break the
    contract on compileOnly dependencies.
   
    Bug: 74477406
    Test: LiveDataQueryTest, InvalidationTrackerTest, NoAppCompatTestApp
    Change-Id: If88114306d7e20ddaed0312a1203a0d14b710145

M       arch/core-testing/src/main/java/androidx/arch/core/executor/TaskExecutorWithFakeMainThread.java
M       room/compiler/src/main/kotlin/androidx/room/solver/query/result/LiveDataQueryResultBinder.kt
M       room/compiler/src/test/data/daoWriter/output/ComplexDao.java
A       room/integration-tests/noappcompattestapp/.gitignore
A       room/integration-tests/noappcompattestapp/README.md
A       room/integration-tests/noappcompattestapp/build.gradle
A       room/integration-tests/noappcompattestapp/src/androidTest/java/androidx/room/integration/noappcompat/BareDatabaseTest.java
A       room/integration-tests/noappcompattestapp/src/main/AndroidManifest.xml
A       room/integration-tests/noappcompattestapp/src/main/java/androidx/room/integration/noappcompat/BareDatabase.java
M       room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/paging/DataSourceFactoryTest.java
M       room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/InvalidationTrackerTest.java
M       room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/LiveDataQueryTest.java
M       room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/QueryTransactionTest.java
A       room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/TestLifecycleOwner.java
A       room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/TestObserver.java
M       room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/TestUtil.java
M       room/runtime/build.gradle
A       room/runtime/src/main/java/androidx/room/InvalidationLiveDataContainer.java
M       room/runtime/src/main/java/androidx/room/InvalidationTracker.java
A       room/runtime/src/main/java/androidx/room/RoomTrackingLiveData.java
A       room/runtime/src/test/java/androidx/room/InvalidationLiveDataContainerTest.kt
M       room/runtime/src/test/java/androidx/room/InvalidationTrackerTest.java
M       settings.gradle

https://android-review.googlesource.com/810053
https://goto.google.com/android-sha1/bab31cacd4ae98057b694f6ae4c781f5f25ee0c9

FYI this requires client to update to Room 2.1.0-alpha03 but it is fully compatible with 1.x that WM uses.

actually it won't work because the change is in generated code. I'll try to backport itinto WM.

re-opening for WM part.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 3fb46bd8602faaf9c34aa969f8ae589c251c2f72
Author: Yigit Boyar <yboyar@google.com>
Date:   Fri Nov 30 13:19:34 2018

    Track LiveData returned by the WM
   
    This CL works around a bug in Room 1.x where LiveData returned
    by Room might be garbage collected.
   
    Now work manager tracks any live data it returns as long as the
    LiveData is active.
   
    Bug: 74477406
    Test: ObserForeverTest, WorkManagerLiveDataTrackerTest
    Change-Id: I1e45dade1e8a3c29d6c35f7cb0c6e072c68ee658

A       work/workmanager/src/androidTest/java/androidx/work/impl/ObserveForeverTest.java
M       work/workmanager/src/main/java/androidx/work/impl/WorkManagerImpl.java
A       work/workmanager/src/main/java/androidx/work/impl/WorkManagerLiveDataTracker.java
A       work/workmanager/src/test/java/androidx/work/impl/WorkManagerLiveDataTrackerTest.java

https://android-review.googlesource.com/838833
https://goto.google.com/android-sha1/3fb46bd8602faaf9c34aa969f8ae589c251c2f72