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.

In SystemJobService, it can expect null, and able to tolerance null from WorkManagerImpl.getInstance, due to auto-backup reason.

@Override
public void onCreate() {
super.onCreate();
mWorkManagerImpl = WorkManagerImpl.getInstance(getApplicationContext());
if (mWorkManagerImpl == null) {
// This can occur if...
// 1. The app is performing an auto-backup. Prior to O, JobScheduler could erroneously
// try to send commands to JobService in this state (

b/32180780

). Since neither
// Application#onCreate nor ContentProviders have run, WorkManager won't be
// initialized. In this case, we should ignore all JobScheduler commands and tell it
// to retry.
But, current WorkManagerImpl.getInstance(Context context) implementation is that, it will never return null but throw IllegalStateException.

Isn't there's conflict among these 2 SystemJobService.onCreate logic, and WorkManagerImpl.getInstance logic?

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

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

commit e14104eb7008f82edd50b37e16bd119b307e0554
Author: Sumir Kataria <sumir@google.com>
Date: Mon Jun 24 10:50:57 2019

Fix for JobScheduler calls when backup is in progress.

The original fix (ag/Ia1604b7c4b98f6b31869e1161a0c1efce7fe46f2) relied
on a null-check, but the new version of WorkManager.getInstance(Context)
with the Context param doesn't return null; it throws an Exception. This
CL updates the three places where we explicitly check for the return value
internally:

1. SystemJobService (the main place where this would manifest)
2. RescheduleReceiver
3. WorkManagerTestInitHelper (for consistency)

Fixes: 135858602
Test: Ran existing tests
Change-Id: Ia232869712d0c78fd80e91d0a863b8c50a080400

M work/workmanager-testing/src/main/java/androidx/work/testing/WorkManagerTestInitHelper.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/RescheduleReceiver.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemjob/SystemJobService.java

https://android-review.googlesource.com/988026

https://goto.google.com/android-sha1/e14104eb7008f82edd50b37e16bd119b307e0554

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

Thanks you so much for the speedy fixed!

May I know when will it be ready for production? As, currently, this IllegalStateException is impacting our users.

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.

Hello. Thanks for respond. I surely will keep a pair of eye on the next release :)

Yes. We don't need on-demand initialization. May I know how does using old (deprecated) WorkManager.getInstance() in our app code, able to bypass this problem? Isn't the crash is origin from library internal SystemJobService?

We once thinking to bypass this problem, by switching back to Version 2.0.1 (The version just before WorkManager.getInstance(Context) is introduced). However, we notice Room version is being changed in between. Downgrading WorkManager version, might cause additional SQLite problem.

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

Sorry, you are correct that moving to the deprecated method will not help you here. I would advise waiting for the release later this week. And thank you very much for finding this bug and doing the research to find the underlying issue.

I am curious: do you actually have reports of this bug on Android 9? It should've been fixed in the platform layer at that point. If possible, can you share any Android 9 specific logs/bugreports/stacktraces with device models?

Issue 202989046