Fixed
Status Update
No update yet.
Comments
di...@google.com
Thanks for reporting, I'm going to look into this.
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 7d4dfd36f1aaba9ca191e5706cb4f4959c38a1a2
Author: Diego Vela <diegovela@google.com>
Date: Fri Oct 15 09:17:25 2021
Use Application Context to get Sidecar.
Use application context to get Sidecar. Using a generic context can
lead to memory leaks. For example using an Activity that doesn't handle
configuration changes will lead to a memory leak when rotating a device.
The reason is that Sidecar captures the Context that is passed in.
Relnote: Fix memory leak.
Bug: 202989046
Bug: 202250276
Test: manual - Use an Activity that ignores config changes.
Test: Install leak canary.
Test: Subscribe to WindowLayoutInfo changes.
Test: Roteate device a few times.
Change-Id: I3fc799fa458528a5cb18dac373aa024f99fa5a6a
M window/window/src/main/java/androidx/window/layout/SidecarCompat.kt
https://android-review.googlesource.com/1859573
Branch: androidx-main
commit 7d4dfd36f1aaba9ca191e5706cb4f4959c38a1a2
Author: Diego Vela <diegovela@google.com>
Date: Fri Oct 15 09:17:25 2021
Use Application Context to get Sidecar.
Use application context to get Sidecar. Using a generic context can
lead to memory leaks. For example using an Activity that doesn't handle
configuration changes will lead to a memory leak when rotating a device.
The reason is that Sidecar captures the Context that is passed in.
Relnote: Fix memory leak.
Bug: 202989046
Bug: 202250276
Test: manual - Use an Activity that ignores config changes.
Test: Install leak canary.
Test: Subscribe to WindowLayoutInfo changes.
Test: Roteate device a few times.
Change-Id: I3fc799fa458528a5cb18dac373aa024f99fa5a6a
M window/window/src/main/java/androidx/window/layout/SidecarCompat.kt
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit a57aa286e34c7d5ce31a0975bde3ff322fa7fcc7
Author: Diego Vela <diegovela@google.com>
Date: Thu Oct 14 16:30:12 2021
Add a sample that does not handle Config changes.
Add a DisplayFeature sample that does not handle configuration changes.
We have a report of a leak in the library. One way to reproduce this is
to launch the DisplayFeature Activity that does not handle
configuration changes and rotate the device multiple times.
Add a dependency on leak canary so that leaks in the samples are
reported in the future.
Bug: 202250276
Bug: 202989046
Test: manual - launch display feature activity without config change
Test: rotate the device a few times and see Leak Canary report a leak.
Change-Id: Iae7a99bb689fff69366f560053ecfecd9e87a2f0
M window/window-samples/src/main/java/androidx/window/sample/demos/WindowDemosActivity.kt
M window/window-samples/src/main/java/androidx/window/sample/DisplayFeaturesNoConfigChangeActivity.kt
M window/window-samples/src/main/res/values/strings.xml
M window/window-samples/src/main/java/androidx/window/sample/DisplayFeaturesConfigChangeActivity.kt
M window/window-samples/src/main/res/layout/activity_display_features_config_change.xml
M window/window-samples/src/main/res/layout/activity_display_features_no_config_change.xml
M window/window-samples/src/main/AndroidManifest.xml
M window/window-samples/build.gradle
https://android-review.googlesource.com/1858796
Branch: androidx-main
commit a57aa286e34c7d5ce31a0975bde3ff322fa7fcc7
Author: Diego Vela <diegovela@google.com>
Date: Thu Oct 14 16:30:12 2021
Add a sample that does not handle Config changes.
Add a DisplayFeature sample that does not handle configuration changes.
We have a report of a leak in the library. One way to reproduce this is
to launch the DisplayFeature Activity that does not handle
configuration changes and rotate the device multiple times.
Add a dependency on leak canary so that leaks in the samples are
reported in the future.
Bug: 202250276
Bug: 202989046
Test: manual - launch display feature activity without config change
Test: rotate the device a few times and see Leak Canary report a leak.
Change-Id: Iae7a99bb689fff69366f560053ecfecd9e87a2f0
M window/window-samples/src/main/java/androidx/window/sample/demos/WindowDemosActivity.kt
M window/window-samples/src/main/java/androidx/window/sample/DisplayFeaturesNoConfigChangeActivity.kt
M window/window-samples/src/main/res/values/strings.xml
M window/window-samples/src/main/java/androidx/window/sample/DisplayFeaturesConfigChangeActivity.kt
M window/window-samples/src/main/res/layout/activity_display_features_config_change.xml
M window/window-samples/src/main/res/layout/activity_display_features_no_config_change.xml
M window/window-samples/src/main/AndroidManifest.xml
M window/window-samples/build.gradle
23...@gmail.com
Comment has been deleted.
di...@google.com
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
Woooooooo tanggg pussy
Description
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