DisplayManagerCompat leaks all used Contexts [279625765]

Fixed

Bug

Status Update

No update yet.

Description

ub...@gmail.com

created issue #1

Apr 25, 2023 06:58PM

Component used: androidx-core

Version used: 1.10.0

Devices/Android versions reproduced on: All

DisplayManagerCompat leaks the Context argument used for DisplayManagerCompat.getInstance(Context). This is easily seen from code inspection:

getInstance(Context) populates DisplayManagerCompat.sInstances, which is of type WeakHashMap<Context, DisplayManagerCompat>.

WeakHashMap has weak keys, not weak values. DisplayManagerCompat.mContext is a hard reference to the same (key) Context object, and therefore causes the entire DisplayManagerCompat instance to leak, including the Context. This circular behavior caveat is spelled out in the javadoc for WeakHashMap.

This issue was one of the root causes for https://issuetracker.google.com/issues/37137738

Comments

al...@google.com <al...@google.com> #2Apr 25, 2023 07:09PM

Accepted by al...@google.com.

In Backward Compatibility (pre Android 13), the configuration is modified at the AppComaptActivity's level and hence the application context not getting modified is intended behaviour. Similar behaviour can be seen for nightMode.

al...@google.com <al...@google.com> #3Apr 26, 2023 04:36PM

Hope this solves the question, please re-open if more information is required.

al...@google.com <al...@google.com> #4Apr 26, 2023 04:39PM

Why is this the intended behavior? Appcompatdelegate that works halfways?
Can someone clarify?

ow...@google.com <ow...@google.com> #5Apr 26, 2023 04:42PM

AppCompatDelegate generally works at the Activity level. This is the case with other features such as NightMode as well. This is why it is intended that it does not affect the application context.

I'm re-assigning this to the team to assess the feasibility of extending the feature to alter the application context.

al...@google.com <al...@google.com> #6Apr 26, 2023 05:10PM

Hello, is there any update regarding to this behavior? Or any known workaround to avoid this issue? Thanks

ap...@google.com <ap...@google.com> #7Apr 26, 2023 08:30PM

Marked as fixed.

We recently added a language picker to our alarm app with ~5M downloads. We were enthused when we heard of Android 13's per-app language capabilities and back-porting.

However, in practice this is a half-baked pre-Android 13 implementation. Anyone who implements it is going to have to handle attachBaseContext() in the Application.kt, Services, and any activity that doesn't extend AppCompatActivity.

If no changes are made, I would at least suggest adding to the Per-app language preferences documentation about the attachBaseContext() for pre-Android 13, and suggested implementation for it - please don't make 1000s of developers write this code :)

Thanks!

na...@google.com <na...@google.com> #8May 10, 2023 07:08PM

It is common use case, to be able to get string from application context besides activity & fragment. If pre-13 unable exhibit same behavior as 13 (able to get localized string from application context), then AppCompatDelegate.setApplicationLocales doesn't solve the backward compatible issue.

Due to this limitation, we can only provide such a dynamic language feature, for Android 13 only.