0

After trying to solve a memory leak issue with the InputMethodManager caused by the keyboard when triggered from a DialogFragment. and other related issues with the imputMethodManager + Dialogs + configurationChanges, which included changes to the manifest like:

android:windowSoftInputMode="adjustPan"
android:windowSoftInputMode="adjustPan|stateUnchanged"

Plus various overrides to onStart(), onStop(), onDestroy() inside Dialog's LifeCycle. Overrides to onDestroy() and onCreate() on Activity.

GlobalLayoutListener's and GlobalFocusChangeListener's with Handlers where also tested.

Changes that for the most part (all of them) have already been discarded as they did not worked.

A portion of the screen began to appear not covered by the default transparency of the DialogFragment on ALL dialog Fragments of the project which include: DialogFragment.class, AppCompatDialogFragment.class and normal AlertDialog.Builder()

I tried to roll back all changes, which at the end, ended up being a single line in FragmentActivity:

@Override
protected void onDestroy() {
    super.onDestroy();
    ViewToolUtils.fixInputMethod(this);
}

Which uses reflection to access the leaking field.

Field declaredField = inputMethodManager.getClass().getDeclaredField("mCurRootView");
                if (declaredField == null) continue;
                if (!declaredField.isAccessible()) {
                    declaredField.setAccessible(true);
                }
                Object obj = declaredField.get(inputMethodManager);
                ...
                declaredField.set(inputMethodManager, null);

, but the uncovered portion of the screen still persists.

Sadly the last version on git was committed before the past week which was dedicated to fix some memory leak issues that were thought to be easily fixable but ended up transforming in some heavy overhauls, so I don't think that's an option...

The changes where first applied on a Samsung j7 Pro, and the dialogs are working with complete normalcy.

But when the changes where tested on a Samsung J5 the project never went back to normal on that device, even when all the changes were rolled back, with caches being invalidated and restarted.

Both devices have been part of this process and the first sign of this issue appeared after this particular fix was applied.

enter image description here

The very suspicious thing about this is that the white uncovered part actually resembles the keyboard... even though is smaller by some millimeters.

I don't mind If I could FORCE the opacity all the way down or DISABLE it entirely, at this point I don't care..., I am kinda desperate tbh.

Delark
  • 1,141
  • 2
  • 9
  • 15
  • 1
    Is this problem visible on dialogs that lack a form of keyboard input? – avalerio Jun 23 '21 at 01:18
  • yes, I have a very basic Dialog without any editText, just 2 buttons and that one is also displaying the same issue as this one. – Delark Jun 23 '21 at 01:22

2 Answers2

1

It seems like this maybe a API level problem I know 4.4.4 - 6.0 all have weird and inconsistent UI oddities. Although you said you reverted it there may be something very small, "unrelated", seemingly benign configuration change.

In the mean time since you are open for work arounds this might help you. DialogFragment with clear background (not dimmed) You could manually set the window to dim and that might override whatever is causing it. If that doesn't work you can set the window to not dim at all and then you can't tell the difference. You could even restrict this to Samsung J5 API level.

avalerio
  • 2,072
  • 1
  • 12
  • 11
  • Thank you very much for your answer, at least the attention helps with the mental state haha. It seems that all it took for it to get fixed was getting a good night sleep. What I guessed happened was that: a) I made an interface with a similar name as one of the packages, and while refactoring a method it changed something in the code (less likely) b) One of the solutions implied connecting a listener to the root view and multiplying it by .15 to figure out whether a keyboard was present Now I believe that for some reason it changed some autogenerated binding values in the default Dialog – Delark Jun 23 '21 at 15:52
0

Well, the solution was forgetting about everything, taking a bath, some pills and going to sleep.

Also some important tips:

  • Optimizing Imports to clear any extra imports.
  • ".txt" everything that is not needed.
  • Comment everything that's not needed.
  • Clearing AS caches + restart,
  • Uninstalling everything from all devices.
  • Clearing the testing DB (Just in case).
  • Rebooting all devices.

That seemed to be the solution.

Delark
  • 1,141
  • 2
  • 9
  • 15