Status Update
No update yet.
Comments
di...@google.com
Attached reproducing video of an app using calculateWindowSizeClass and LocalConfiguration:
On the second time resizing to be 50%/50% from smaller, the displayed configuration is incorrect.
ap...@google.com
When resizing the activity in multi-window mode under those conditions, there are cases where:
the Activity is not recreated Activity.onConfigurationChanged is not called View.onConfigurationChanged is not called
Is this just for 33 / is there a framework bug filed? The amount of broken things in configuration land we already had to workaround in Compose is a bit untenable. It seems like we are missing a lot of test coverage in the platform to avoid these issues hitting us in the future
ap...@google.com
In any case this seems like more ammunition for us to push more strongly on 'pure-compose apps should always opt out of configuration changes'
23...@gmail.com
di...@google.com
I was incorrect, this is also reproducible on API 32 as well. Not reproducible on API 31.
su...@gmail.com
Adam/Louis, how do we want to handle this one? Is there someone on platform who should take this, or since API 32 is already out in the wild maybe this should go to devrel to push more strongly on 'pure-compose apps should always opt out of configuration changes'.
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