The null check is redundant since instanceof does it for you.

Same comment as above.

There's an edge case when dealing with fragments: since the activity and child fragment managers are different, findFragmentByTag could still return null even if the dialog is showing in another manager. AFAIK, it doesn't matter which fragment manager is used to display a dialog so the SupportFragmentPermissionHelper could look like this to fix the bug:

@Override
public FragmentManager getSupportFragmentManager() {
 Fragment f = getHost();
 FragmentActivity activity = f.getActivity();
 if (activity != null) {
 return activity.getSupportFragmentManager();
 } else {
 // Not sure what else we can do here
 return f.getChildFragmentManager();
 }
}

TBH, this edge case should be so rare that it doesn't really matter... your call.

Thanks for the tip! I'll do what you suggested.

Man child fragment managers are a special kind of no fun.

Edit: Nevermind. I just saw that there is a new version of the library (1.1.3) which has this fixed.

When a permission is requested from a support library Fragment this implementation of SupportFragmentPermissionHelper.getSupportFragmentManager() will prevent the Fragment from receiving the onRequestPermissionsResult() callback.
I was debugging a case when a rationale dialog was shown, followed by the system's Request permission dialog. As the Activity's fragment manager is used, it's the Activity which has its onRequestPermissionsResult() called, and not the Fragment's one

@Zhelyazko thanks for the comment anyway!