Activity.windowInfoRepository() leaks the activity [202989046]

Fixed

Bug

Status Update

No update yet.

Description

sm...@gmail.com

created issue #1

Oct 14, 2021 02:18AM

Component used: Window
Version used: 1.0.0-beta02
Devices/Android versions reproduced on: Android 11 (real and emulator)

Essentially the logic is setup a sample project with a fragment and invoke the windowInfoRepository() method with an activity. That causes the ExtensionWindowBackend.globalInstance to hold on to the activity's context. Perhaps using the application context would be better, but I don't know how the context is used.

For example I am using Kotlin and only do the following to get the window metrics to replace deprecated code in Android 12.

val metrics = activity?.windowInfoRepository()?.currentWindowMetrics?.firstOrNull()?.bounds

Stack trace of the leak:

┬───
│ GC Root: Input or output parameters in native code
│
├─ okio.AsyncTimeout class
│ Leaking: NO (PathClassLoader↓ is not leaking and a class is never leaking)
│ ↓ static AsyncTimeout.$class$classLoader
├─ dalvik.system.PathClassLoader instance
│ Leaking: NO (ExtensionWindowBackend↓ is not leaking and A ClassLoader is
│ never leaking)
│ ↓ ClassLoader.runtimeInternalObjects
├─ java.lang.Object[] array
│ Leaking: NO (ExtensionWindowBackend↓ is not leaking)
│ ↓ Object[].[7701]
├─ androidx.window.layout.ExtensionWindowBackend class
│ Leaking: NO (a class is never leaking)
│ ↓ static ExtensionWindowBackend.globalInstance
│ ~~~~~~~~~~~~~~
├─ androidx.window.layout.ExtensionWindowBackend instance
│ Leaking: UNKNOWN
│ Retaining 125.0 kB in 2848 objects
│ ↓ ExtensionWindowBackend.windowExtension
│ ~~~~~~~~~~~~~~~
├─ androidx.window.layout.SidecarCompat instance
│ Leaking: UNKNOWN
│ Retaining 124.9 kB in 2844 objects
│ ↓ SidecarCompat.sidecar
│ ~~~~~~~
├─ androidx.window.sidecar.SettingsSidecarImpl instance
│ Leaking: UNKNOWN
│ Retaining 124.6 kB in 2832 objects
│ mContext instance of com.example.MyActivity with
│ mDestroyed = true
│ ↓ SettingsSidecarImpl.mContext
│ ~~~~~~~~
╰→ com.example.MyActivity instance
Leaking: YES (ObjectWatcher was watching this because com.example.MyActivity
received Activity#onDestroy() callback and
Activity#mDestroyed is true)
Retaining 115.4 kB in 2676 objects
key = 169cb8aa-ce65-4d85-ad39-a03daaad93f7
watchDurationMillis = 5190
retainedDurationMillis = 190
mApplication instance of com.example.Application
mBase instance of androidx.appcompat.view.ContextThemeWrapper

METADATA

Build.VERSION.SDK_INT: 30
Build.MANUFACTURER: Google
LeakCanary version: 2.7
App process name: com.example.debug
Count of retained yet cleared: 4 KeyedWeakReference instances
Stats: LruCache[maxSize=3000,hits=9130,misses=169317,hitRate=5%]
RandomAccess[bytes=9274118,reads=169317,travel=111728236112,range=42477374,size=
51517143]
Heap dump reason: 18 retained objects, app is visible
Analysis duration: 86480 ms

Comments

di...@google.com <di...@google.com> #2Oct 14, 2021 10:13PM

Accepted by di...@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

ap...@google.com <ap...@google.com> #3Oct 15, 2021 07:36PM

The following changes were cherrypicked through Coastguard (

https://android-build.googleplex.com/coastguard/)
Release Track: (

https://android-build.googleplex.com/coastguard/dashboard/6093116828680192/#/cherrypickHistory/all)
Created: 2019-10-14 17:23:42.610596+00:00
Changes: aosp/1123258

ap...@google.com <ap...@google.com> #4Oct 19, 2021 11:23PM

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 (

b/140759491

).
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

23...@gmail.com <23...@gmail.com> #5Oct 23, 2021 03:32PM

Comment has been deleted.

Message last modified on Oct 25, 2021 04:19PM

di...@google.com <di...@google.com> #6Oct 28, 2021 02:44AM

Marked as fixed.

The first issue should be fixed. We are going to update the API to make other memory more clear and easier to avoid. Thanks for reporting. If you still see a leak please let us know. Thanks for reporting the issue.

su...@gmail.com <su...@gmail.com> #7Mar 4, 2022 05:24AM

Woooooooo tanggg pussy

Issue 202989046