时间戳

首页 > 解决方案 > 此泄漏是否是由 Android 11 DP2 引起的

leakcanary - 此泄漏是否是由 Android 11 DP2 引起的

问题描述

我在 Pixel 4 XL 上使用 Android 11 DP2，从那以后，我经常遇到这种泄漏。我怀疑它是由开发人员预览引起的，但我并不完全确定。

我试图在网上搜索这个泄漏，但我没有找到任何相关的东西。

你怎么看？

┬───
│ GC Root: System class
│
├─ android.app.ApplicationPackageManager class
│    Leaking: NO (a class is never leaking)
│    ↓ static ApplicationPackageManager.mHasSystemFeatureCache
│                                       ~~~~~~~~~~~~~~~~~~~~~~
├─ android.app.ApplicationPackageManager$1 instance
│    Leaking: UNKNOWN
│    Anonymous subclass of android.app.PropertyInvalidatedCache
│    ↓ ApplicationPackageManager$1.mCache
│                                  ~~~~~~
├─ android.app.PropertyInvalidatedCache$1 instance
│    Leaking: UNKNOWN
│    Anonymous subclass of java.util.LinkedHashMap
│    ↓ PropertyInvalidatedCache$1.tail
│                                 ~~~~
├─ java.util.LinkedHashMap$LinkedHashMapEntry instance
│    Leaking: UNKNOWN
│    ↓ LinkedHashMap$LinkedHashMapEntry.key
│                                       ~~~
├─ android.app.ApplicationPackageManager$HasSystemFeatureQuery instance
│    Leaking: UNKNOWN
│    ↓ ApplicationPackageManager$HasSystemFeatureQuery.this$0
│                                                      ~~~~~~
├─ android.app.ApplicationPackageManager instance
│    Leaking: UNKNOWN
│    ↓ ApplicationPackageManager.mContext
│                                ~~~~~~~~
├─ android.app.ContextImpl instance
│    Leaking: UNKNOWN
│    ↓ ContextImpl.mAutofillClient
│                  ~~~~~~~~~~~~~~~
╰→ com.example.app.ui.activities.SplashActivity instance
​     Leaking: YES (ObjectWatcher was watching this because com.example.app.ui.activities.SplashActivity received Activity#onDestroy() callback and Activity#mDestroyed is true)
​     key = 6a69a2a3-1d38-4d27-8c4c-cae915bea1b1
​     watchDurationMillis = 15093
​     retainedDurationMillis = 10089

METADATA

Build.VERSION.SDK_INT: 29
Build.MANUFACTURER: Google
LeakCanary version: 2.2
App process name: com.example.app
Analysis duration: 4326 ms```

标签： leakcanary

解决方案

是的，这很可能是 Android 漏洞。不知道它是不是新的，但我以前没见过。你对自动填充有什么特别的吗？

您应该在 Android 错误跟踪器上报告它，最好使用示例项目来重现它。如果您不能轻松重现，至少提供指向堆转储的链接将有助于调查。

根据泄漏跟踪中涉及的名称，如果 ApplicationPackageManager 具有应用程序范围（因此没有泄漏），则 ContextImpl.mAutofillClient 持有活动引用的时间过长。

该字段在这里定义：https ://android.googlesource.com/platform/frameworks/base/+blame/master/core/java/android/app/ContextImpl.java#235

我还没有发现自动填充的任何最新变化可以解释这种泄漏。我们可以在 Activity 的源代码中看到，当一个 Activity 附加了它的基本上下文时，它会将自己设置为该基本上下文的自动填充客户端：https ://android.googlesource.com/platform/frameworks/base/+blame/ master/core/java/android/app/Activity.java#1124

它永远不会自行取消设置，因此要么这是错误，要么基础上下文应该与活动具有相同的范围。

我觉得奇怪的另一件事是static ApplicationPackageManager.mHasSystemFeatureCache，这意味着 ApplicationPackageManager 有一个以 m 开头的静态字段（成员字段）。这是一个奇怪的名字，通常是在 android 源代码中不会发生的错误。事实上我找不到它：https ://android.googlesource.com/platform/frameworks/base/+blame/master/core/java/android/app/ApplicationPackageManager.java但也许他们没有分享更新来源呢？你在什么设备上使用这个？

推荐阅读